API RESTful создает глобально уникальный ресурс

В нашей системе есть учетные записи, содержащие элементы. Элемент всегда связан с одной учетной записью, но также имеет глобальный уникальный идентификатор в системе. Иногда желательно работать с элементом, когда известен только его идентификатор.

Неправильно ли разрешать доступ к подчиненному ресурсу (элементу) вне его владельца (учетной записи)? Другими словами, неправильно ли иметь 2 URI одного и того же ресурса? Это немного сложно объяснить, поэтому вот пример:

POST /inventory/accountId
  #Request Body contains new item 
  #Response body contains new item id

GET|PUT|DELETE /inventory/accountId/guid  #obviously works and makes sense

GET|PUT|DELETE /inventory/guid  #does this make sense?

Возможно, мне следует пересмотреть макет ресурсов и не использовать учетные записи для создания элементов, но вместо этого взять учетную запись в качестве параметра строки запроса или поля в элементе?

POST /inventory
  # Request body contains item w/ account name set on it

GET|POST|DELETE /inventory/uuid  #makes sense

GET|POST|DELETE /inventory/accountId/uuid #not allowed

Ответы

Ответ 1

POST /inventory/accountId
GET|PUT|DELETE /inventory/accountId/guid  #obviously works and makes sense
GET|PUT|DELETE /inventory/guid  #does this make sense?

Это имеет наибольший смысл, когда /inventory/guid перенаправляется на /inventory/accountId/guid (или, я бы спорил, наоборот). Наличие единственной канонической сущности, с множественным перенаправлением URI на нее, позволяет вашей схеме кэширования оставаться наиболее простой. Если два URI вместо этого возвращают одни и те же данные, то пользователь неизбежно отправит новое представление в одно, а затем путается, когда он ПОЛУЧИТ старую копию из другой, потому что кеш был только недействительным для первого. Аналогичная проблема может возникнуть для последующих GET на двух. Перенаправления сохраняют это намного чище (не совсем синхронно, но чище).

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

Ответ 2

Я думаю, что наличие двух URI указывает на один и тот же элемент, который требует неприятностей. По моему опыту, такие вещи приводят к сумасшествию, когда вы масштабируетесь (кеширование, множественные узлы в кластере, выходящие из синхронизации и т.д.). Пока идентификатор элемента действительно глобально уникален, нет причин просто не ссылаться на него как /inventory/uid

Ответ 3

Другими словами, неправильно ли иметь 2 URI для одного и того же ресурса?

Нет. Неправильно иметь несколько URI, идентифицирующих один и тот же ресурс. Я не вижу ничего плохого в вашем первом подходе. Помните, что URI являются уникальными идентификаторами и должны быть непрозрачными для клиентов. Если они однозначно идентифицируют ресурс, вам не нужно слишком беспокоиться о том, чтобы ваши URL выглядели красиво. Я не говорю, что моделирование ресурсов не важно, но ИМО мы не должны тратить на это слишком много времени. Если ваш бизнес нуждается в том, что у вас есть руководство непосредственно под инвентаризацией, а также под отдельными учетными записями, пусть будет так.

Ответ 4

Вы обеспокоены этим из-за потенциальной дыры в безопасности, позволяющей предоставлять данные для неавторизованных пользователей? Или ваше беспокойство связано исключительно с дизайном?

Если безопасность не является для вас проблемой, я согласен с тем, что совершенно нормально иметь 2 URIS, указывающих на один и тот же ресурс.