REST API Best Practice?

Question

[Artem0071]

Тут вышла статья на хабре, но как и в остальных таких постах не смог для себя обнаружить одну, но немаловажную вещь

Везде описывается только отдельные категории, такие как /cats или /dogs
Но что делать с вариантом при которых нам нужно получить не только модель или не только его друзей, а модель и дополнительные параметры, например при dashbord'e? То есть мы получаем некую базу по "коту" и еще некоторые данные которые есть на странице

Как мне получить cat и всех его друзей?
/cats/1(id некого кота)/friends?
Окей, а что делать если мне необходимо получить не только его друзей, но еще и некоторую дополнительную информацию, например лотки в которых он ...?
/cats/1/friends_and_wc? но это глупо, мы можем ошибиться в написании в определенном порядке, да и вариантов может быть больше чем 2
или
/cats/1/frieds/wc?
Или нам придется создавать 2 отдельных запроса?
Или нам лучше использовать какие то дополнительные параметры?
Например
/cats/1?extra=friends,wc

В общем есть ли тут какое то наиболее "Best Practice" решение?

Answer 1

[Сергей Горностаев]

Best Practice как раз в том, чтобы проектировать слабосвязанные системы, а не навешивать на один эндпоинт кучу функций.

Answer 2

[Игорь Русинов]

У нас используется следующий подход:
Есть основной ресурс, например /cats/1 в вашем случае. Есть дополнительные атрибуты: /cats/1/friends , /cats/1/wc. Если нужно получить множество атрибутов за раз, то используется GET параметр with: /cats/1?with=friends,wc. При этом если такой атрибут не может понадобиться отдельно от основного ресурса, то для него вообще не создается отдельный url, и он просто получается с помощью параметра with.
Это чем то похоже на GraphQL, но проще в реализации. Хотя если у вас множество типов с данных со сложными связями, возможно именно GraphQL подойдет вам лучше.

Answer 3

[Виталий]

на мой взгляд и gql может быть тоже использован в простых запросах.
по мне не надо циклиться на уровне моделей, так как это концепция простых и не сильно зависящих друг от друга данных. мы называем эндпоинт именем таблицы и методом запроса определяем что мы с этим делаем, это же уровень блога или списка новостей.
а как быть , когда при обращении к 1 эндпоинту выполняется запрос к бд на 100 строк? какой там gql ? все эти упрощения для обычных и ежедневных задач, если требуется выполнять нетривиальные действия, то нужно планировать свою концепцию апи и забивать на ограничивающие тебя рекомендации.
например /api/сущность/действие
Зачем вообще задумываться как на твою объективно нужную классификацию апи наименования посмотрят другие? у тебя есть задача, ты ее решаешь и все.