Comments 8
Единый интерфейс. Реализация приложения отделена от сервиса, который оно предоставляет. То есть пользователь знает, что оно делает и как с ним взаимодействовать, но как именно оно это делает не имеет значения. При изменении приложения, интерфейс остаётся прежним, и клиентам не нужно подстраиваться.
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_5
https://ru.wikipedia.org/wiki/REST#4._Единообразие_интерфейса
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Развиваемому вместе с HTTP Роем Филдингом, REST'у было предназначено использовать HTTP 1.1, в качестве транспорта.
Не было. REST как архитектурный стиль не ограничивает приложение конкретным протоколом, о чем сам Филдинг писал как в диссертации, так и позже в своем блоге.
Возможные сценарии описываются термином CRUD — Create, Read, Update, Delete.
CRUD не является частью ограничений ни REST, ни HTTP.
POST используется для создания нового объекта в наборе объектов. Или более сложным языком: для создания нового подчинённого ресурса.
Включая, но не ограничиваясь. Метод POST предназначен для передачи данных на сервер с целью дальнейшей обработки — он используется для любых действий, которые не нужно стандартизировать в рамках HTTP. До RFC 5789 он был единственным легальным способом вносить частичные изменения.
https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
https://tools.ietf.org/html/rfc7231#section-4.3.3
Не было. REST как архитектурный стиль не ограничивает приложение конкретным протоколом, о чем сам Филдинг писал как в диссертации, так и позже в своем блоге.
Да, но фактически, насколько мне известно, используется только HTTP и только 1.1
CRUD не является частью ограничений ни REST, ни HTTP.
Да, но я и не утверждаю этого. Хотя, возможно, и стоит поменять формулировку на более мягкую.
Включая, но не ограничиваясь. Метод POST предназначен для передачи данных на сервер с целью дальнейшей обработки
Спасибо, поправлю.
Возможно, со временем я напишу обзорную или сравнительную статью о разных API, но пока это подготовительная статья к следующей, поэтому задача была по камешкам разобрать именно RESTful API.
Отличная статья и всё хорошо разжевали доступным языком. Но… Поставьте на сайт HTTPS, жесть же когда при переходе по Вашей ссылке выдается Warning и нужно подтверждение перехода.
WEB-сервисы, удовлетворяющие всем принципам REST, называются RESTful WEB-services.
У меня, наверное, глупый вопрос, но всё же: а как Web-сервис может не удовлетворять принципам REST?
Мне более-менее понятно только с принципом Stateless — не храним ничего в сессии, ОК.
Но что касается первого требования: разве не любой Web-сервис обеспечивает взаимодействие клиента с сервером?
Как может быть нарушено третье требование — тоже не очень понятно. Если в запросе содержится вся требуемая информация, то зачем бы может понадобиться менять интерфейс при изменении приложения?
К uniform я тоже привёл очень краткое описание. Более полному не соответствовать совсем нетрудно:
As the constraint name itself applies, you MUST decide APIs interface for resources inside the system which are exposed to API consumers and follow religiously. A resource in the system should have only one logical URI, and that should provide a way to fetch related or additional data. It’s always better to synonymize a resource with a web page.
Any single resource should not be too large and contain each and everything in its representation. Whenever relevant, a resource should contain links (HATEOAS) pointing to relative URIs to fetch related information.
Also, the resource representations across the system should follow specific guidelines such as naming conventions, link formats, or data format (XML or/and JSON).
All resources should be accessible through a common approac
Автоматизация Для Самых Маленьких. Заметки. RESTful API