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

Question

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

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

POST /inventory/accountId
  #Request Body contains new item 
  #Response body contains new item's 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

Answer 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 на двух. Перенаправления сохраняют это намного чище (не совсем синхронно, но чище).

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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