Один маршрут для всех операций API

Question

Я работаю над API, используя Laravel 5.6, для приложения, в котором меня попросили предложить один маршрут для всех операций, которыми можно управлять с помощью отправленных параметров. Делая это таким образом, предполагается облегчить работу интерфейсных разработчиков, когда ему / ей не нужно беспокоиться о различных вызываемых маршрутах, потому что один маршрут делает все это.

Таким образом, будет один контроллер со всеми соответствующими функциями в одном методе. Различные операции над различными таблицами следует дифференцировать на основе заданных параметров и ничего больше.

Итак, я просто хотел знать, целесообразно ли продолжать этот подход, потому что я никогда не работал над такой концепцией.

Answer 1

Как упоминалось ранее, все это будет в значительной степени зависеть от модели данных, что не ясно из вашего вопроса.

Итак, главный вопрос в том, какие данные предоставит API?

Но, не зная этого, предлагаемое решение не похоже на хороший подход ко мне.

Минусы, с которыми я бы пошел:

1. Похоже, что бэкэнд исправляет отсутствие структуры во внешнем интерфейсе.

   Обычно разные компоненты внешнего интерфейса полагаются на разные конечные точки API. Смешивание этого приведет к затруднению поддержки кода на всех фронтах.

2. Фронтенд должен беспокоиться о том, что они называют.

   Я не вижу логики в том, что веб-интерфейс знает , какие параметры они хотят отправить, но они не хотят знать , куда его отправлять?

3. Поддержка кода API была бы плохой в пользу внешнего интерфейса? Что не имеет смысла для меня, это вернется и будет преследовать вас.

4. Вы добавляете ненужные и ненужные сложности в API.

   Подумайте, как бы вы справились с проверкой ввода, и как бы вы вернули это во внешний интерфейс.

За что это стоит;

Обычно я начинаю с плоского API REST, непосредственно на моделях баз данных, чтобы разрешить простой CRUD и список с простыми операциями фильтрации / сортировки / подкачки.

Для Laravel это означало бы использование контроллеров ресурсов поверх вашей сущности, что открыло бы конечные точки CRUD для этой сущности.

Это предоставит простой интерфейс, в котором клиенты могут получить / создать / обновить один объект.

Кроме того, и, при необходимости , я создам дополнительные конечные точки API, если этого потребует конкретный интерфейс / использование, и, кроме того, имело бы смысл перенести эту функциональность в API / Backend.