Наименование ресурса REST API по пути - PullRequest
Новая
       7

Наименование ресурса REST API по пути

1 голос
/ 17 июня 2019

При чтении «Рекомендации по REST API» часто рекомендуется называть ресурсы по иерархии, например: 

https://api.example.com/projects/{projectid}/documents/{documentid}

Теперь я хотел бы назвать ресурсы по пути, который может иметь любую глубину, чтобы ресурс (например, проект) мог быть расположен так: 

 https://api.example.com/projects/{group}/{projectname}

или 

https://api.example.com/projects/{group}/{subgroup}/{projectname}

Но теперь именование ресурсов по иерархии неоднозначно, потому что: 

https://api.exmaple.com/projects/mygroup/mysubgroup/projectname/documents/document1

Может относиться к проекту document1 по пути /mygroup/mysubgroup/projectname/documents/, что неверно.

Также действия над проектом, такие как: 

https://api.exmaple.com/projects/mygroup/mysubgroup/projectname/edit

У меня такая же проблема.

Каким будет RESTful способ работы с ресурсами, названными path, которые имеют иерархию?

Ответы [ 2 ]

1 голос
/ 17 июня 2019

Каким будет RESTful способ работы с ресурсами, названными путем, которые имеют иерархию?

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

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

/documents/{id}

/projects/{id}

/groups/{id}

Короткие URI легче запомнить, и вы всегда можете использовать параметры запроса для фильтрации ресурсов.

Примечание 1: Синтаксис URI определен в RFC 3986 .Как правило, путь организован в иерархической форме (с сегментами, разделенными /) и может содержать неиерархические данные в компоненте запроса (начиная с ?).

Примечание 2: Архитектурный стиль REST описан в главе 5 диссертации Роя Т. Филдинга и определяет набор ограничений, которым должны следоватьприложения, которые следуют такой архитектуре.Однако в нем ничего не говорится о том, какими должны быть URI.

Примечание 3: Примеры популярной статьи написано Мартином Фаулером, объясняющим модель, определенную Леонардом Ричардсоном предлагает структуру URI, которая выглядит дружественной и легкой для чтения.

1 голос
/ 17 июня 2019

Я думаю, что на этот вопрос нельзя ответить, только что обсудили.

Для приложения CRUD рассмотрите возможность использования плоских путей с уникальным идентификатором ( URI ) длякаждый ресурс.

/groups/:id
/documents/:id
/projects/:id

Затем свяжите свои сущности с необходимостью и добавьте дополнительные конечные точки для запросов.

Пример: 

/search?group=id&subgroup=id&document=id&project=id

В более продвинутом REST Подход HTTP-Path более независим от самого ресурса.Отправляя HTTP-запрос, вы спрашиваете об определенном представлении «некоторого» ресурса.Это выражается не только путем, но и типом (отправка в заголовке HTTP).Ваш клиент может позвонить ... 

GET -H"accept:application/vnd.myapi.subgroup" /documents/document1

..., что может привести к ответу, отличному от 

GET -H"accept:application/vnd.myapi.document" /documents/document1
...