Кто занимается планированием REST API в SPA приложении?

Question

[Андрей Попов]

Подскажите пожалуйста как организовать командную работу?
В команде 1 фронтендер и 1 бекендер. Задача сделать SPA приложение с REST API на бекенде.
Кто из них должен продумывать то какие ендпоинты и структура данных должны быть у REST API?
1. Фронтендер делает фронт и по мере необходимости говорит бекендеру какие ему нужны API ендпоинты и с какими данными
2. Бекендер самостоятельно проектирует API, а фронтендер подстраивается под его структуру
3. Или есть другие варианты?

Comments

[N]

Я (в роли бекендера) обычно сам проектировал API...ну какие-то моменты согласовывали...
Но тут должно быть понимание в том, чтобы фронтендеру не приходилось делать "лишнего", так же как и бекендеру, потому что "фронтендеру", например, "так удобнее"...

Минимум запросов и параметров для достижения того или иного результата - я такого правила стараюсь придерживаться.

Answer 1

[Denis]

Тип который знает бизнес модель описывает девелоперам, потом бек строит апи, а фронт строит фронт, каждый уже примерно должен знать что ему нужно и фронт может успешно строить свои интерфейсы объектов для моков а потом уже может мапить поля с апи, если хочется попытаться договориться чтоб меньше мапить то есть стандарты описания респонса к примеру https://jsonapi.org/

Answer 2

[Владимир Коротенко]

В общем смотрите
Первоначально приходит бизнес аналитик и составляет ТЗ
Бэк делают по ТЗ
Фронт делают по ТЗ
На бэке документируется через www.swagger.io
или через любой другой инструмент https://habr.com/ru/post/252237/

В общем где то так.
Если вы прокинули ТЗ и БА, то созванивайтесь и сами уточняйте

Comments

[Владимир Коротенко]

BonBon Slick, Лол низачет.

Answer 3

[Sergey]

Тот "тип", который описывает модель - называется аналитик.
Составьте mind map карту, опишите структуру, создайте спринты, в спринтах опишите структуру, мелкие задачи вешайте как смарт задачи.

Answer 4

[Saboteur]

пусть сядут вместе, обсудят политику. В идеале, чтобы проектировал более опытный, но им разве мешает кто-то общаться?
Главное, чтобы зафиксированные вещи были где-то записаны. Типа один сказал "нужно такое", второй просмотрел, убедился что это реализуемо и выглядит нормально, законфирмил.
После этого можно начинать работать независимо, можно сделать для бэкенда два этапа - когда бэкенд сделает ендпоинт с заглушкой, и когда он сделает полноценный ендпоинт.

Для записи можно использовать UML