Правильный способ проектирования конечных точек

Question

Я проектирую ОТДЫХ. У меня есть пользователь, и у пользователя есть контакты разных типов. Какими должны быть мои конечные точки в соответствии с REST?

Это выглядит разумно:

GET /users/:id/contacts

GET /contacts

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

GET /contacts?user_id=:id

И заставить эту конечную точку вернуть все контакты. И это делает конечную точку для пользователей избыточной.

Как правильно сделать это в соответствии с REST?

Answer 1

Какими должны быть мои конечные точки в соответствии с REST? [...] Как правильно сделать это в соответствии с REST?

Это заблуждение .

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

---

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

Так что /users/{id}/contacts, кажется, просто прекрасно идентифицировать набор контактов, принадлежащих определенному пользователю .

---

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

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