RESTful API создает глобально уникальный ресурс - PullRequest
Новая
       8

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

1 голос
/ 12 июля 2011

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

Неправильно ли разрешать доступ к подчиненному ресурсу (предмету) извне его владельца (учетной записи)? Другими словами, неправильно ли иметь 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

Ответы [ 4 ]

2 голосов
/ 13 июля 2011

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

1 голос
/ 12 июля 2011

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

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

1 голос
/ 12 июля 2011 
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 на двух.Перенаправления обеспечивают большую чистоту (не совсем синхронную, но более чистую).

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

1 голос
/ 12 июля 2011

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

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

...