Должен ли элемент в REST API возвращать собственный идентификатор?
В чем преимущество возврата идентификатора элемента? Разве он уже не является частью URL-адреса и, следовательно, не известен? Я не говорю об использовании REST API с HAL или чем-то подобным.
api/employees/1
{
"Id" : 1
"Name" : "Joe Bloggs",
"Department" : "IT"
}
api/employees/1
{
"Name" : "Joe Bloggs",
"Department" : "IT"
}
Думаю, имеет смысл добавить дополнительную информацию об использовании API:
Рассматриваемый API - это общедоступный API в закрытой сети (не в Интернете). Мы предоставляем образцы клиентов, но наши клиенты пишут свой собственный клиент для нашего API. Идентификатор элемента не является конфиденциальной информацией. Данные не о бывших сотрудниках (как указано в вопросе), а об управлении активами.
Причина, по которой я спрашиваю, заключается в том, что клиенты жалуются, что если они используют какое-то промежуточное программное обеспечение (каким бы оно ни было), они получают только содержимое элемента, но не имеют доступа к URL-адресу элемента (как?).
Если вы пишете свой собственный клиент, существует ли какая-либо ситуация, когда вы не можете получить идентификатор на основе URL-адреса? Стоит ли добавлять ID для людей, у которых почему-то нет доступа к URL?
Ответы 1
Для чего на самом деле клиент использует идентификатор? Представление идентификатора продукта не является неправильным IMO, но должен ли пользователь знать идентификатор, который вы храните в базе данных пользователя, когда она в любом случае использует электронную почту для аутентификации с помощью API? Итак, чтобы ответить на актуальный вопрос: это зависит от обстоятельств. Однако, если клиент использует его для создания следующего URI для вызова, я настоятельно рекомендую вместо этого возвращать ссылки со значимыми именами отношений, поскольку это помогает отделить клиента от API, поскольку клиент не должен иметь априорных знаний о сам API.
В зависимости от ресурса может быть нецелесообразно иметь возрастающий идентификатор, поскольку это может способствовать атакам наугад, а также может привести к странной ситуации, если вы удалите элемент в середине коллекции. Обновляются ли идентификаторы последующих элементов? Обнаружен ли зазор между предметами? Обычно более безопасный способ раскрытия такой информации - идентификаторы UUID и т.п.
Еще один аспект, который следует учитывать, заключается в том, что клиенты в идеальной среде REST не должны интерпретировать сами URI, а должны вместо этого использовать имя отношения, для которого был возвращен URI, чтобы определить, вызывать этот URI или нет. Клиент, который извлекает идентификатор из URI, скорее всего, имеет некоторые априорные знания об API и, таким образом, тесно связан с этим API и наверняка сломается, если API когда-либо будет изменен.
При этом существует концепция шаблонов URI, которые должны помочь клиенту извлекать такие вещи, как идентификаторы и имена из URI. Лично я не слишком увлечен такими вещами, поскольку они продвигают вводящий в заблуждение подход к применению REST в дизайне API.
If you write your own client, is there any kind of situation where you can't get the ID based on the URL? Should we add the ID for people, who somehow do not have access to the url?
Извлечение идентификатора URI требует знания структуры URI. Если вы когда-нибудь когда-нибудь захотите изменить структуру URI по какой-либо причине, все клиенты, которые были построены на основе этих знаний, сломаются. URI не должны содержать контент, так как тело на самом деле существует. Поскольку идентификатор кажется довольным для некоторых клиентов, включите его в тело ответа. Вы, конечно, можете добавить некоторую информацию в URI, хотя вам не нужно требовать от клиентов синтаксического анализа этого URI и извлечения из него необходимой информации.