Що таке RESTful програмування?
!"ВІДПОЧИНОК" є основним архітектурним принципом Інтернету. Дивовижність Інтернету полягає в тому, що клієнти (браузери) і сервери можуть взаємодіяти складними способами без того, щоб клієнт заздалегідь знав що-небудь про сервер і ресурси, які на ньому розміщені. Ключовим обмеженням є те, що сервер і клієнт повинні домовитися про медіа, що використовується, яким у випадку Інтернету є HTML*.
API, який дотримується принципів REST, не вимагає, щоб клієнт знав що-небудь про структуру API. Навпаки, сервер повинен надати будь-яку інформацію, необхідну клієнту для взаємодії з сервісом. Прикладом цього є HTML-форма: Сервер вказує місце розташування ресурсу і необхідні поля. Браузер не знає заздалегідь, куди подавати інформацію, і не знає заздалегідь, яку інформацію подавати. Обидві форми інформації повністю надаються сервером. (Цей принцип називається HATEOAS: Hypermedia As The Engine Of Application State).
Отже, як це стосується HTTP, і як це може бути реалізовано на практиці? HTTP орієнтований на дієслова та ресурси. Два дієслова в основному використовуються - це GET
і POST
, які, я думаю, кожен впізнає. Однак, стандарт HTTP визначає кілька інших, таких як PUT
і DELETE
. Ці дієслова потім застосовуються до ресурсів, відповідно до інструкцій, наданих сервером.
Наприклад, уявімо, що у нас є база даних користувачів, яка управляється веб-сервісом. Наш сервіс використовує власний гіпермедіа на основі JSON, для якого ми призначаємо міметип application/json+userdb
(також може бути application/xml+userdb
і application/whatever+userdb
- може підтримуватися багато типів медіа). Клієнт і сервер запрограмовані на розуміння цього формату, але вони нічого не знають один про одного. Як зазначає Рой Філдінг:
"REST API повинен витрачати майже всі свої описові зусилля на
визначенні типу(ів) медіа, що використовуються для представлення ресурсів та керування стану додатку, або на визначення розширених імен відношень та/або гіпертекстової розмітки для існуючих стандартних типів медіа.
Запит до базового ресурсу /
може повернути щось подібне:
Запит
GET /
Accept: application/json+userdb
Відповідь
200 OK
Content-Type: application/json+userdb
{
"version": "1.0",
"links": [
{
"href": "/user",
"rel": "list",
"method": "GET"
},
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
З опису наших медіа ми знаємо, що можемо знайти інформацію про пов'язані ресурси з розділів, які називаються "посиланнями". Це називається Керування гіпермедіа. В даному випадку ми можемо сказати з такого розділу, що ми можемо знайти список користувачів, зробивши ще один запит на /user
:
Запит
GET /user
Accept: application/json+userdb
Відповідь
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"
}
]
}
Ми можемо багато чого дізнатися з цієї відповіді. Наприклад, тепер ми знаємо, що можемо створити нового користувача за допомогою POST
до /user
:
Запит.
POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Karl",
"country": "Austria"
}
Відповідь
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"
}
}
Ми також знаємо, що можемо змінити існуючі дані:
Запит
PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Emil",
"country": "Bhutan"
}
Відповідь
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"
}
}
Зверніть увагу, що ми використовуємо різні HTTP-дієслова (GET
, PUT
, POST
, DELETE
тощо) для маніпулювання цими ресурсами, і що єдине знання, яке ми припускаємо з боку клієнта - це наше визначення медіа.
Читати далі:
(Ця відповідь була предметом критики за те, що вона не розкриває суті питання. Здебільшого це була справедлива критика. Те, що я спочатку описав, більше відповідало тому, як REST зазвичай реалізовувався кілька років тому, коли я вперше написав це, а не його справжньому значенню. Я переглянув відповідь, щоб краще відобразити справжнє значення).
REST використовує різні методи HTTP (в основному GET/PUT/DELETE) для маніпулювання даними.
Замість того, щоб використовувати конкретний URL для видалення методу (скажімо, /user/123/delete
), ви відправляєте запит DELETE на URL /user/[id]
, для редагування користувача, щоб отримати інформацію про користувача, ви відправляєте запит GET на /user/[id]
.
Наприклад, замість цього ви отримаєте набір URL-адрес, які можуть виглядати наступним чином.
GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1
Ви використовуєте HTTP &quo ;дієслова&quo ; і маєте...
GET /user/2
DELETE /user/2
PUT /user
Це програмування, де архітектура вашої системи відповідає стилю REST, викладеному Роєм Філдінгом в його дисертації. Оскільки це архітектурний стиль, який описує веб (більш-менш), багато людей цікавляться ним.
Бонусна відповідь: Ні. Якщо ви не вивчаєте архітектуру програмного забезпечення як академічну дисципліну або не розробляєте веб-сервіси, то немає жодної причини чути цей термін.