Можно, а то и нужно, но если вы к этому подойдете с позиции аля "бекенд не знает ничего о приложении" - будет хреново.
Антон Бреславский, что значит требование заказчика? Это требование было в ТЗ, но архитектура не предусмотрела? Косяк архитектора, как я и написал.
Требования не было в ТЗ? Заказчик идёт нахрен или заключает новый договор на много денег, т.к. данное изменение требует переработки архитектуры. Не вижу ничего необычного.
Будет он каждый раз дергать запрос и 1 000 000 строк или сделает слой.
Утрируя: для фронта это разница меж /get/uuid и /uuid/get, для бэка это полная переделка всего кода или костыль с вытягиванием половины базы на каждый запрос.
Мне кажется проблема в том, что бекенд разработчики не верно понимают разработку бизнес-логики и разработку интерфейса доступа к ней и к данным. Интерфейс на бекенд может быть HTTP, сокеты ли даже командная строка. Это всего лишь интерфейс. Эти разработчики при проектировании ендпойнта /login часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить например GraphQL им нужно дублировать функционал.
Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно? Такого кейса нет? Фронты не могут предложить вариант как это видят? Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами. Вы спокойно пойдете делать и они тоже. Потом через какое-то время вы соединитесь и проверите, что ваш контракт выполнен. Что тут не так?
@model()
export class User {
@field({jsonFieldName: 'first_name'})
firstName: string;
}
http.get('/users/1').pipe(map(resp => deserialize(resp, User))snack_case, у нас нормальный cameCase.
про дизайнера - нет. Ни фига не понятно, что он там нарисовал и какая там логика кроется за каждой кнопкой.
Если выше написанное не про вас, не воспринимайте на свой счет, если что-то зацепило - то стоит задуматься.
Поэтому вопрос не в том, что "фронтенд проектирует API и делает это всегда плохо", а в том, что по вашему описанию, вы сейчас руководствуетесь неправильными принципами подходя к проектированию API, это и есть проблема.
/login часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить например GraphQL им нужно дублировать функционал.