REST adalah prinsip arsitektur web yang mendasarinya. Hal yang luar biasa tentang web adalah kenyataan bahwa klien (browser) dan server dapat berinteraksi dengan cara yang rumit tanpa klien mengetahui apa pun sebelumnya tentang server dan sumber daya yang dihostingnya. Kendala utama adalah bahwa server dan klien harus menyetujui media yang digunakan, yang dalam hal web adalah HTML .
API yang menganut prinsip REST tidak mengharuskan klien untuk mengetahui apa pun tentang struktur API. Sebaliknya, server perlu memberikan informasi apa pun yang dibutuhkan klien untuk berinteraksi dengan layanan. Sebuah bentuk HTML adalah contoh dari ini: Server menentukan lokasi sumber daya dan bidang yang diperlukan. Browser tidak tahu sebelumnya di mana harus mengirimkan informasi, dan tidak tahu sebelumnya apa informasi yang harus dikirimkan. Kedua bentuk informasi sepenuhnya disediakan oleh server. (Prinsip ini disebut HATEOAS : Hypermedia Sebagai Engine of Application State .)
Jadi, bagaimana ini berlaku untuk HTTP , dan bagaimana itu bisa diimplementasikan dalam praktik? HTTP berorientasi pada kata kerja dan sumber daya. Dua kata kerja dalam penggunaan arus utama adalah GETdan POST, yang saya pikir semua orang akan kenal. Namun, standar HTTP mendefinisikan beberapa yang lain seperti PUTdan DELETE. Kata kerja ini kemudian diterapkan pada sumber daya, sesuai dengan instruksi yang diberikan oleh server.
Misalnya, Mari kita bayangkan bahwa kita memiliki basis data pengguna yang dikelola oleh layanan web. Layanan kami menggunakan hypermedia khusus berdasarkan JSON, untuk itu kami menetapkan mimetype application/json+userdb(Mungkin juga ada application/xml+userdbdan application/whatever+userdb- banyak jenis media mungkin didukung). Klien dan server keduanya telah diprogram untuk memahami format ini, tetapi mereka tidak tahu apa-apa tentang satu sama lain. Seperti yang ditunjukkan oleh Roy Fielding :
REST API harus menghabiskan hampir semua upaya deskriptifnya dalam menentukan jenis media yang digunakan untuk mewakili sumber daya dan status aplikasi mengemudi, atau dalam mendefinisikan nama hubungan yang diperluas dan / atau mark-up yang memungkinkan hypertext untuk jenis media standar yang ada.
Permintaan untuk sumber daya dasar /mungkin mengembalikan sesuatu seperti ini:
Permintaan
GET /
Accept: application/json+userdb
Tanggapan
200 OK
Content-Type: application/json+userdb
{
"version": "1.0",
"links": [
{
"href": "/user",
"rel": "list",
"method": "GET"
},
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Kami tahu dari uraian media kami bahwa kami dapat menemukan informasi tentang sumber daya terkait dari bagian yang disebut "tautan". Ini disebut kontrol Hypermedia . Dalam hal ini, kami dapat memberi tahu dari bagian seperti itu bahwa kami dapat menemukan daftar pengguna dengan mengajukan permintaan lain untuk /user:
Permintaan
GET /user
Accept: application/json+userdb
Tanggapan
200 OK
Content-Type: application/json+userdb
{
"users": [
{
"id": 1,
"name": "Emil",
"country: "Sweden",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
{
"id": 2,
"name": "Adam",
"country: "Scotland",
"links": [
{
"href": "/user/2",
"rel": "self",
"method": "GET"
},
{
"href": "/user/2",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/2",
"rel": "delete",
"method": "DELETE"
}
]
}
],
"links": [
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Kami bisa tahu banyak dari respons ini. Misalnya, kita sekarang tahu bahwa kita dapat membuat pengguna baru dengan POSTcara /user:
Permintaan
POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Karl",
"country": "Austria"
}
Tanggapan
201 Created
Content-Type: application/json+userdb
{
"user": {
"id": 3,
"name": "Karl",
"country": "Austria",
"links": [
{
"href": "/user/3",
"rel": "self",
"method": "GET"
},
{
"href": "/user/3",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/3",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Kami juga tahu bahwa kami dapat mengubah data yang ada:
Permintaan
PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Emil",
"country": "Bhutan"
}
Tanggapan
200 OK
Content-Type: application/json+userdb
{
"user": {
"id": 1,
"name": "Emil",
"country": "Bhutan",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Perhatikan bahwa kita menggunakan kata kerja HTTP yang berbeda ( GET, PUT, POST, DELETEdll) untuk memanipulasi sumber daya ini, dan bahwa satu-satunya pengetahuan kita anggap pada bagian klien adalah definisi media kita.
Bacaan lebih lanjut:
(Jawaban ini telah menjadi subyek cukup banyak kritik karena melewatkan poin. Sebagian besar, itu adalah kritik yang adil. Apa yang saya jelaskan sebelumnya lebih sesuai dengan bagaimana REST biasanya diterapkan beberapa tahun yang lalu ketika saya pertama menulis ini, daripada arti sebenarnya. Saya telah merevisi jawaban untuk lebih mewakili makna sebenarnya.)
