HATEOAS связывает с PUT/POST
Каков наилучший способ представить ссылку на HATEOAS для POST/PUT/PATCH на ресурсе? Эти операции имеют полезную нагрузку, но у нас не будет возможности представить полезную нагрузку в ссылке HATEOAS, поскольку они не определены заранее и могут быть тяжелыми. Так будет ли достаточно просто указать конечную точку и указать операцию?
Любые образцы или примеры будут очень благодарны за ответ JSON с HATEOAS POST/PUT/PATCH ссылка на сайт.
1 ответ
Ссылки состоят из двух элементов: href а также rel, href содержит явный URL для поиска ресурса. rel определяет связь между текущим ресурсом и ресурсом ссылки. rel следует использовать, чтобы определить, какой метод HTTP является приемлемым и как должна использоваться ссылка.
Ниже приводится цитата из раздела 5.4 Поваренной книги веб-служб RESTful:
Тип отношения ссылки передает роль или назначение ссылки. Как только клиенты и серверы сошлись во мнении о значении этих типов, клиенты могут находить и использовать URI из ссылок.
Например, edit является стандартным ссылочным отношением, которое имеет явные детали, включая подробности об использовании GET, PUT, POST, DELETE,
Отношения ссылок могут быть расширены, и вы можете добавить свои собственные.
У этих операций есть полезная нагрузка, но у нас не будет возможности отображать полезную нагрузку в ссылке HATEOAS, поскольку они не определены заранее и могут быть тяжелыми?
Обычный ответ заключается в том, что вы документируете операции в своем описании типов мультимедиа, которые вы используете для своих представлений.
Одна из ссылок, которую следует учитывать, - это Atom Syndication/Atom Pub. Основная идея состоит в том, что спецификация медиа-типа сообщает вам, как интерпретировать документ, включая интерпретацию отношений ссылок.
См. Также Fielding, 2008.
REST API должен тратить почти все свои описательные усилия на определение типов мультимедиа, используемых для представления ресурсов и управления состоянием приложения, или на определение расширенных имен отношений и / или разметки с поддержкой гипертекста для существующих стандартных типов мультимедиа. Любые усилия, затраченные на описание того, какие методы использовать для интересующих URI, должны быть полностью определены в рамках правил обработки для типа мультимедиа.
Как правило, PUT и PATCH должны быть довольно простыми - это методы удаленного создания; тело запроса PUT обычно является просто отредактированной версией представления, предоставляемого GET, а PATCH - это просто другой способ описания изменений (обычно с использованием одного из типов мультимедиа, описанных заголовком Accept-Patch).
POST - сложный метод, поскольку семантика POST имеет очень свободные ограничения, поэтому существует множество степеней свободы. Если вы не можете описать дополнительные ограничения в строке, вам следует больше полагаться на свое определение типа носителя.