Каков предпочтительный дизайн Restful URI, чтобы различать коллекцию и одноэлементный ресурс? - PullRequest
Новая
       13

Каков предпочтительный дизайн Restful URI, чтобы различать коллекцию и одноэлементный ресурс?

1 голос
/ 29 июня 2011

У меня есть структура URI, которая является иерархической для определенного набора данных: 

/Blackboard/Requirement/{reqID}/Risk/{riskId}/MitigationPlan/{planId}

Если URL разделен на различные идентификаторы, вы можете получить этот конкретный ресурс, например ::10000 

GET: /Blackboard/Requirement/2/Risk/2

Это получает риск № 2, связанный с требованием № 2

Вопрос заключается в следующем: желаемая функция теперь может обновлять (PUT) и удалять (DELETE) набор требований в одном и том же HTTP-запросе. (Весь «набор» требований может быть GET, когда вы запускаете HTTP GET по URL-адресу /Blackboard - это функциональность по умолчанию, поскольку что-то написано на доске, образно)

Итак, я должен создать новый URL ресурса коллекции, поддерживающий только PUT / DELETE, например: 

/Blackboard/Requirements : HTTP PUT/DELETE

(обратите внимание на множественное число)

или фактически сделать существующую структуру URL множественной 

/Blackboard/Requirements/{reqID}/Risk/{riskId}/MitigationPlan/{planId}

Последнее, похоже, нарушает семантическое единообразие, поскольку другие элементы в иерархии единичны. Должен ли я сделать их тоже во множественном числе ??

Помогает ли наличие идентификатора элемента устранять неоднозначность (с человеческой точки зрения :), например Blackboard/Requirements/1, или предпочтительнее предоставлять другой ресурс (т. Е. Коллекцию) исключительно по эксплуатационным причинам (поскольку GET не допускается без идентификатора - независимо от того, единственное или множественное число)?

Просто хотел узнать мнение сообщества о том, какой подход обычно выбирается (или является правильным способом сделать это) для ясности и чистоты дизайна.

1 Ответ

1 голос
/ 30 июня 2011

Последнее, кажется, нарушает семантическую однородность, поскольку другие элементы в иерархии являются единичными.Должен ли я сделать их множественным числом тоже?

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

Помогает ли наличие идентификатора предмета устранять неоднозначность (с человеческой точки зрения :), как Blackboard / Requirements / 1, или предпочтительнее выставлять другой ресурс (т.е.коллекция) исключительно по эксплуатационным причинам (поскольку GET не допускается без идентификатора - независимо от того, является ли он единственным или множественным числом)?

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

...