Должны ли модули / контроллеры на основе REST разделяться по ресурсам или действиям / функциям - PullRequest
Новая
       4

Должны ли модули / контроллеры на основе REST разделяться по ресурсам или действиям / функциям

0 голосов
/ 07 марта 2020

У меня есть сценарий использования, который выглядит следующим образом:

API1: выбор всех книг в США, принадлежащих Джону: GET Request на /country/us/person/john/books

API2: выбор всех книг, принадлежащих Джон во всех странах: GET Request на /person/john/books

API3: Получить все книги во всех странах: GET Request на /country/books

Я хочу построить сервер отдыха, используя NestJS (но это не слишком важно для этого вопроса), который использует понятия modules для организации controllers.

В этом примере я должен иметь:

  • module называется books с 1 controller, передавая 3 маршрута. Или,
  • 2 modules, booksByCountry и booksByPerson

Есть ли рекомендуемый способ думать об этом?

1 Ответ

0 голосов
/ 09 марта 2020

Это зависит от того, как вы хотите настроить свой API семантически.
Для меня, в соответствии с вашими вариантами использования и доступом к ресурсам, так как вы хотите получать ресурсы книг по человеку и / или по стране, я бы go примерно так:

Первый способ мышления:

API1: получить все книги в США, принадлежащие Джону:
GET Запрос на /books/person/{personName}/country/{countryName}

API2: получение всех книг, принадлежащих Джону во всех странах:
GET Запрос на /books/person/{personName}

API3: получение всех книг во всех странах :
GET Запрос на /books

Другой способ думать об этом:

API1: получить все книги в США, принадлежащие Джону:
GET Запрос на /persons/{personName}/books?country={countryName}

API2: Получить все книги, принадлежащие Джону во всех странах:
GET Запрос на /persons/{personName}/books?country=all (или /persons/{personName}/books, если вы не Не нужно обрабатывать все значение параметра запроса)

API3: получить все книги во всех странах:
GET Запрос на /books

Вывод:

Все зависит от согласованности семантических c ваших URI и способа обработки параметров пути и запроса. Независимо от того, хотите ли вы опубликовать свой API или только для внутреннего использования, сделайте его простым и последовательным, как вы предоставляете свои ресурсы, чтобы ваши потребители не потеряли при чтении документов и использовании вашего API.

Позвольте мне знать, если это помогает, также приветствуются комментарии и другие POV по этому вопросу!

...