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

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, которая выглядит дружественной и легкой для чтения.}