Должен ли элемент в REST API возвращать свой собственный идентификатор? - PullRequest
Новая
       6

Должен ли элемент в REST API возвращать свой собственный идентификатор?

0 голосов
/ 23 мая 2018

В чем выгода возврата идентификатора элемента?Разве это уже не часть 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?Должны ли мы добавить идентификатор для людей, которые почему-то не имеют доступа к URL?

1 Ответ

0 голосов
/ 23 мая 2018

Для чего клиент фактически использует идентификатор?Представление идентификатора продукта не является неправильным IMO, но должен ли пользователь знать идентификатор, в котором вы сохраняете сущность пользователя в БД, когда он в любом случае использует электронную почту для аутентификации с помощью API?Итак, чтобы ответить на актуальный вопрос: это зависит.Однако, если клиент использует его для создания следующего URI для вызова, я настоятельно рекомендую вместо этого возвращать ссылки с содержательными именами отношений, поскольку это помогает отделить клиента от API, поскольку клиент не должен заранее знатьсам API.

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

Еще один аспект, который следует учитывать, заключается в том, что клиенты в идеальной среде REST не должны интерпретировать URI, а вместо этого использовать имя отношения, для которого был возвращен URIопределить, вызывать ли этот URI или нет.Клиент, который извлекает идентификатор из URI, скорее всего, имеет некоторые априорные знания об API и, таким образом, тесно связан с этим API и с уверенностью сломается, если API когда-либо будет изменен.

С учетом вышесказанного, существует концепция шаблонов URI, которая должна помочь клиенту в извлечении таких вещей, как идентификаторы и имена из URI.Лично я не очень заинтересован в таких вещах, поскольку они продвигают вводящий в заблуждение подход к применению REST в дизайне API.

Если вы пишете свой собственный клиент, есть ли ситуации, когда выне могу получить идентификатор на основе URL?Должны ли мы добавить идентификатор для людей, которые каким-то образом не имеют доступа к URL?

Для извлечения идентификатора URI требуется знание структуры URI.Если вы когда-нибудь захотите изменить структуру URI по какой-либо причине, то все клиенты, построенные на этих знаниях, сломаются.URI не должны содержать контент, так как тело фактически там.Поскольку идентификатор, по-видимому, является контентом для некоторых клиентов, включите его в тело ответа.Вы, конечно, можете добавить некоторую информацию в URI, хотя вам не нужно требовать, чтобы клиенты анализировали этот URI и извлекали необходимую информацию.

...