Должен ли ответ RESTful GET возвращать идентификатор ресурса?

Это вопрос личного мнения, а не тот вопрос, который любит видеть Stackoverflow. в любом случае предложу свою.

Вы возвращаете представление состояния объекта или ресурса. Идентификатор является частью этого представления и, следовательно, должен быть включен в пакет JSON. Это свойство ресурса. Независимо от того, знает ли звонящий идентификатор или нет, не имеет особого отношения к обсуждению. ЛАГЕРЬ №1 стоит на шаткой почве.

То, что вы говорите о коллекциях, очень актуально. Имеет ли смысл использовать одно представление для операции retrieve-1 и другое представление для операции retrieve-N? Думаю, нет.

Однако проблема, с которой вы сталкиваетесь, носит более общий характер - какие данные должны быть включены в представление, передаваемое клиентам, и при каких обстоятельствах? В некоторых случаях вызывающий абонент просто не заботится о значительном подмножестве свойств. Особенно в сценариях, где извлекается большой набор объектов - где стоимость передачи данных больше по сравнению с базовой стоимостью связи - вы хотите оптимизировать то, что отправляется обратно.

Все достаточно зрелые протоколы REST имеют возможность формировать возвращаемые данные.

Примеры см.

• API Facebook Graph, http://developers.facebook.com/docs/reference/api/ < / а>
• API StackExchange v2.0 - есть объект «фильтр», который вы можете передать, чтобы точно сформировать то, что возвращается.
• API CouchDb - имеет функцию карты для каждого представления, которая определяет, какие данные будут возвращены. Он также имеет параметр общего запроса include_docs, который указывает серверу включать полные объекты или только метаданные. (В некоторых случаях вам может понадобиться только количество данных, а не фактические данные.)

вы можете увидеть это в действии на странице https://api.stackexchange.com/docs/answers.

... и, в частности, смотрите диалог спецификации фильтра.

Не существует единственно правильного способа делать что-либо. Вам необходимо сбалансировать сложность поддерживаемой вами функции «формирования» со стоимостью разработки и потребностями приложений, которые будут использовать API.

Старый вопрос, но раз уж я попал сюда в поисках чего-то, вот еще одно мнение:

Прежде всего, я думаю, что URL-адрес должен быть:

http://my.api.com/rest/Users/23

нет

http://my.api.com/rest/getUsers/23

«GET» относится к методу HTTP, а не к URL-адресу. Это просто наименование, но помогает прояснить ситуацию, ИМХО.

Если вы думаете об этом, изменение ресурса должно произойти в том же URL-адресе с PUT

ПОСТАВИТЬ http://my.api.com/rest/Users/23

В этом случае клиенту необходимо отслеживать URL-адреса, а не идентификаторы. Не имеет значения, возвращает ли ресурс поле идентификатора. Клиент должен сохранить карту того, откуда он был получен.

Если вы попытаетесь ПОЛУЧИТЬ восстановление на другой URL, скажите «http://my.api.com/rest/Users/24 ", может произойти несколько сценариев:

1) http://my.api.com/rest/Users/24 уже существует на сервере и сервер принимает ресурс как обновление

2) http://my.api.com/rest/Users/24 не существуют на сервере и:

a) сервер принимает, что пользователь предоставляет идентификатор (24) несуществующему ресурсу (не рекомендуется) b) сервер принимает PUT как POST

В a + b сервер создаст новый ресурс.

So:

1) В зависимости от того, насколько вы доверяете своему клиенту, вам, вероятно, следует создать на сервере элемент управления «регистрация / выписка», чтобы избежать перезаписи одного ресурса другим (это RESTful?)

2) Вы не должны принимать клиентов, создающих идентификаторы (ОК, чтобы опубликовать http://my.api.com/rest/Users/, а не http://my.api.com/rest/Users/24), и вам не следует принимать PUT для несуществующих ресурсов.

ИЗМЕНИТЬ:

Поэтому я считаю, что ресурс идентифицируется по URL-адресу, а не по идентификатору. Или, другими словами, идентификатор ресурса - http://my.api.com/rest/Users/23, а не 23.

Имеет смысл?