В соответствии с просьбой я отправил свой комментарий в качестве ответа и добавил некоторые подробности, чтобы вообще быть полезен.
Общий метод создания новых ресурсов по HTTP POST - это возврат кода состояния 201 Created. Следовательно, ответ должен содержать текущее состояние ресурса как тело субъекта и заголовок местоположения, указывающий на URI, что ресурс может быть найден. Не делать этого, может сломать некоторых клиентов и предотвратить их правильное взаимодействие с сервисом. Клиентами могут быть браузеры, индивидуальные приложения languageOfYourChoice или даже другие сервисы.
В идеальном мире RESTful клиент знает только об одном единственном URI, чтобы начать (например, входной URI службы, например, http://service.company.com/). Ответ вызова этого URI должен вернуть документ, который может быть понят клиентом, и содержит дополнительные ссылки, которые клиент может использовать, если они заинтересованы. Эта концепция похожа на HTML-файл большого брата и аналогичные веб-ресурсы, используемые людьми каждый день, когда ссылки могут использоваться для перехода от начальной страницы к подстраницам или даже к внешним ресурсам или другим ресурсам гиперссылок. REST - это просто абстракция и обобщение веб-вещи.
Несмотря на то, что этот вопрос не является частью фактического вопроса, и это скорее основано на мнениях, между RESTful devolopers обсуждается полезность общих и специализированных типов документов (типы mime, ...). Я думаю, что должен быть стандартизованный общий формат REST для JSON, XML, ... Просто просто application/json недостаточно, так как это не определяет, как должны включаться ссылки и схемы. Даже HAL недостаточно описателен (IMO) относительно исполняемых действий в URI и каких форматах документов ожидать при вызове этих URI и какие аргументы необходимо передать службе.
Форматы документов (типы носителей a.k.a) являются одной из основных концепций акронима Roy Fieldings HATEOAS. Клиентам не нужны никакие предварительные знания, отличные от точки входа, и типы медиа, понятные клиентам (таким образом, предыдущий абзац). Все возможные действия описываются с помощью спецификации протокола HTTP и понимания того, что выражают соответствующие типы носителей.
Поэтому, возвращая URI вместо идентификатора имеет несколько преимуществ:
- URIs сам по себе уникальным, разным производителям, хотя могут иметь одинаковые идентификаторы
- Клиент не нуждается знаний о том, как сервер создавая эти URI, сервер, с другой стороны, может предоставить их почти бесплатно. Возврат идентификатора продукта
1234 имеет почти мгновенные способы объединения в URI клиентом - поэтому клиенту необходимы специальные знания о том, как создать URI, чтобы сервер действительно мог правильно обработать запрос.
- Сервер может перемещать ресурсы без необходимости изменения клиентов, поскольку клиенты (в идеальном мире RESTful) будут получать URI ресурса в ответ на дополнительный запрос. Поэтому клиенту требуется только семантическое знание того, что возвращаемое поле «означает»
При успешном создании нового ресурса вы должны вернуть ответ кода состояния «201 Created», который включает в себя заголовок «Местоположение», указывающий на URI, где новый ресурс можно найти - по крайней мере, это общий подход. Просто включение идентификатора ресурса в ответе не является RESTful, поскольку это заставляет клиента иметь некоторую логику о сервере и его структуре. Подобно веб-ресурсам, вы хотите сохранить только один URI - точку входа. Все другие ссылки получаются через обмен сообщениями/ответами –
Не должен ли этот комментарий быть поднят до фактического ответа? – morsor
@ RomanVottner не знает, какой возвращаемый идентификатор ресурса или весь новый ресурс имеет общее с * логикой о сервере и инфраструктуре *? Не могли бы вы прояснить? – Opal