REST - это основной архитектурный принцип сети. Удивительным моментом в Интернете является тот факт, что клиенты (браузеры) и серверы могут взаимодействовать сложным образом, и клиент ничего не знает заранее о сервере и размещенных на нем ресурсах. Ключевым ограничением является то, что сервер и клиент должны согласовать используемое мультимедиа , которое в случае с Интернетом является HTML .
API, который придерживается принципов REST , не требует от клиента ничего знать о структуре API. Скорее, сервер должен предоставить любую информацию, необходимую клиенту для взаимодействия со службой. Форма HTML является примером этого: Сервер определяет местоположение ресурса и требуемых полей. Браузер не знает заранее, куда отправить информацию, и он не знает заранее, какую информацию отправлять. Обе формы информации полностью предоставляются сервером. (Этот принцип называется HATEOAS : гипермедиа как двигатель состояния приложения .)
Итак, как это относится к HTTP , и как это может быть реализовано на практике? HTTP ориентирован на глаголы и ресурсы. Два глагола в основном употреблении - GETи POST, и я думаю, что все узнают. Тем не менее, стандарт HTTP определяет несколько других, таких как PUTи DELETE. Эти глаголы затем применяются к ресурсам в соответствии с инструкциями, предоставленными сервером.
Например, давайте представим, что у нас есть пользовательская база данных, которая управляется веб-службой. Наша служба использует пользовательский гипермедиа , основанный на формате JSON, для которых мы относим MimeType application/json+userdb(Там также может быть application/xml+userdbи application/whatever+userdb- многие типы данных могут быть поддержаны). Клиент и сервер были запрограммированы для понимания этого формата, но они ничего не знают друг о друге. Как отмечает Рой Филдинг :
API-интерфейс REST должен потратить почти все свои описательные усилия на определение типов носителей, используемых для представления ресурсов и управления состоянием приложения, или на определение имен расширенных отношений и / или разметки с поддержкой гипертекста для существующих стандартных типов носителей.
Запрос на базовый ресурс /может вернуть что-то вроде этого:
Запрос
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 обычно применялся несколько лет назад, когда я сначала написал это, а не его истинное значение. Я пересмотрел ответ, чтобы лучше представить реальное значение.)
