REST vs RESTful. В чём Разница? Окончание
Начало
RPC через HTTP vs RESTful
Часто говорят, что сервис «не REST», из-за неправильных URI или использования глаголов HTTP. Имеется в виду представление данных REST как единообразного набора ресурсов.
Это различие иногда формулируется как различие между вызовами удаленных процедур (RPC) и REST. Представьте себе веб-сервис для перечисления, добавления и удаления товаров онлайн-магазина.
В одной версии есть один URL, который мы запрашиваем с помощью HTTP GET или POST. Вы взаимодействуете с сервисом, отправляя данные POST, содержащие то, что вы хотите сделать. Например, добавить элемент с помощью NewItem:
POST /inventory HTTP/1.1
{
"NewItem": {
"name": "new item",
"price": "9.99",
"id": "1001"
}
}
Запросить через POST и ItemRequest:
POST /inventory HTTP/1.1
{
"ItemRequest": {
"id": "1001"
}
}
Некоторые реализации также допускают запросы через GET-параметры:
POST /inventory?id=1001 HTTP/1.1
И т.п.
Это не REST. Мы не обмениваемся состоянием ресурсов. Мы вызываем функцию с аргументами, которые находятся в документе JSON или параметрая URL.
RESTful-сервис имеет URI для каждого ресурса. Поэтому добавление нового товара будет выглядеть так же, как в примере выше. Но на этом сходства заканчиваются.
Запрос элемента – это всегда GET:
GET /item/1001 HTTP/1.1
Удаление - DELETE:
DELETE /item/1001 HTTP/1.1
Изменение - PUT:
PUT /inventory HTTP/1.1
{
"Item": {
"name": "new item",
"price": "7.99",
"id": "1001"
}
}
Разница важна. В REST операции используют различные глаголы HTTP, которые соответствуют действиям с данными: GET, POST, PUT, DELETE и PATCH имеют определённые контракты. Большинство хорошо спроектированных REST API также возвращают определённые коды HTTP в зависимости от результата запроса. Основным различием является то, что URI соответствуют данным, а не удалёнными методам.
REST против RESTful и модель зрелости Ричардсона
Разработка URI в соответствии с ресурсами и использование глаголов HTTP способствует предсказуемости API. Когда разработчики поймут, как вы структурировали ресурсы, они смогут сделать обоснованные прогнозы относительно структуры API. В этом смысле основное внимание уделяется пониманию самих данных, а не связанных с ними операций.
Но даже если вы не можете сделать API полностью предсказуемым, вы можете документировать любой REST-сервис с помощью HATEOAS. Тогда каждый элемент, возвращаемый сервером, будет содержать ссылки для удаления или изменения ресурса.
Многие сайты не соответствуют этому требованию, но по-прежнему называются REST. Леонард Ричардсон создал модель уровней зрелости REST:
0 – API через HTTP с вызовом удалённых методов с аргументами.
1 – Использование ресурсов вместо методов.
2 – Правильное использование HTTP-глаголов.
3 – Использование HATEOAS, что делает видимым весь API или его часть.
По Филдингу требуется третий уровень, так что большинство приложений не являются REST.
То, насколько хорошо архитектура соответствует стандарту, не так важно, как то, насколько хорошо она соответствует потребностям и может расти вместе с бизнесом.
Архитектурный шаблон REST имеет множество преимуществ. Филдинг разработал его для Интернета, и 18 лет спустя большинство ограничений, которые он добавил, все ещё с нами. В 2000 году у нас не было Android или iPhone, а IE5 занимал 50% рынка браузеров. Но Филдинг понимал, что нужно онлайн-приложениям и как веб-клиенты будут развиваться от механизмов отображения HTML в полноценные приложения. Инструменты, которые мы используем сегодня, адаптированы к REST, а не наоборот.
Модель зрелости Ричардсона — хорошее руководство для разработки приложений. Желательно находиться на втором уровне модели и посмотреть, как третий уровень может улучшить ваш дизайн.
Источник: https://blog.ndepend.com/rest-vs-restful/