Как передать на бекенд требования к API?

Спасибо за конструктивный ответ! То есть бекенд тратит время, что бы накидать примерный JSON и описание ендпойнтов в тексте, а фронт потом тратит время что бы это, если что поправить и переслать?

Что если они кинут ссылку на спеку и в реальном времени будут накидывать и править Swagger - их будущий контракт? Потом на беке появиться реальный сваггер и мы сможем сматчить его со спецификацией? Всегда поймем, что пропущено, всегда сможем что-то добавить? Не в тексте в тасках, а в спецификации?

Например вот так

Как передать на бекенд требования к API?

Спасибо большое за ответ. Но обязательно переходить на личности?

Судя по вашим фразам, Вы скорее всего один из них.

Это такой формат общения: унизить и оскорбить прежде, чем ответить? Не важно какой у меня опыт 5 или 15 лет. Если Вы бекенд разработчик, значит у Вас предвзятое отношение к фронту или Вы работали только с плохими фронтент разработчиками и у вас какая-то обида на них? Они вас не ценили?

Я за свою карьеру успел поработать на всех местах, и могу сказать, что и там и там не просто и везде своя специфика. Не важно пишите Вы огромный запрос в базу или в браузере пытаетесь сделать бесконечный скролл, что бы тот не завис. Это не простые задачи.

Вопрос не в том, что фронтенд проектирует API и делает это всегда плохо, а в том, что может предложить как и какие данные он хочет получить от бэка. Для этого и есть Swagger в YAML. Если бэкенд видит это по другому, они тут же внесут изменения в спеку, но у них будет готовый контракт, что бы работать параллельно: один на моках, другой с реальной базой, так нельзя делать? Или это не оптимально?

Как передать на бекенд требования к API?

Василий Банников, тогда двойная работа и узкое место :-) Задача по синхронизации работы не решена.

Спасибо за Ваши ответы и участие в дискуссии.

Как передать на бекенд требования к API?

Василий Банников, так они не знают еще нейминг полей и моделей? Откуда им накидывать?

Как передать на бекенд требования к API?

Василий Банников, ну там же не написано какого цвета :-) Получается пока бэк не сделал API и модель данных, фронты не работают? Он же не знают нейминг полей, входные параметры и т.д.?

Как передать на бекенд требования к API?

Василий Банников, тогда, что является отправной точкой для всех них? Фича с описанной историей? По ней дизайнер нарисовал как видит. По ней же бек написал API. По ней же фронт намокал данные. Так?

Как передать на бекенд требования к API?

Василий Банников, спасибо! Сильный аргумент! Мы забыли про историю пользователя, если конечно ее написали.

Как передать на бекенд требования к API?

Agent Smith, тогда все таки, за наличие API отвечает наличие требования в дизайне?
Значит дизайн это отправная точка для API, а Вы говорите не пишут.

Видим, что виджет есть, нужно особым образом вывести данные, значит и ендпойнт нужен.

в хорошей команде такие элементарные вопросы даже не обсуждаются. Всё делается на автомате

Чистый Agile и все сеньоры? А если дать мидлу и джуну запилить какую-то не сложную фичу.
Пусть спроектирует API, сеньор проверит и заапрувит. Есть такой сценарий?

Как передать на бекенд требования к API?

Agent Smith, это очень странно звучит.

API по дизайну НЕ ПИШУТ!

Как же тогда понять, что например нужен API /news/summaryчто бы вывести в виджете в боковой панели кол-во новостей в каждой категории? Экономика - 5, Технологии - 10 и т.д. Откуда бэку знать об этом? Менеджер проекта должен сам это понять и поставить такую задачу?

Как передать на бекенд требования к API?

Василий Банников, так все же вопрос не раскрыт :-) Кто пишет апи по дизайну, бэк или фронт?

Как передать на бекенд требования к API?

Василий Банников, а причем тут бэк придумал? Придумал дизайнер, он придумал картинку, которая понравилась пользователю. Мы отдаем ее бэку и он накидывает код и уже генерит сваггер и говорит фронту, вот для этой картинки такой API?

Если что-то сложное, то вместе сидим, думаем какие будут параметры, и что будет возвращаться.

В результате есть описание на выходе, нейминг полей или считается, что все друг друга поняли?

Как передать на бекенд требования к API?

Какие ендпоинты где дёргаются - это фронты и так хорошо знают.

А когда проект большой? Каждый работает над разными фичами. Где им соединиться в одинаковых ендпойнтах? На разных экранах могут дергаться одни и те же ендпойнты. Бэка еще нет, где смотреть, что уже спроектировано для бэка?

Как передать на бекенд требования к API?

Спасибо за ответ!

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

А как они у Вас договариваются? Сидят рядом, пишут JSON?

Зачем в стиле гуглодоков, когда есть swaggerUI? А доступ по ссылке можно реализовать буквально в пару строчек.

Спеку хранить в одном YAML god файле? А как его редактировать совместно?

Бэкендеру знать о том, как работает фронт не обязательно.

Верно, ему даже дизайн видеть не нужно, тогда как понять, что нужно сделать? Значит ему должны написать Swagger в любом случае. Как ему его передать? Как потом его актуализировать вместе? Как сравнивать с его Swagger генерируемый из кода?

Как передать на бекенд требования к API?

TheAndrey7, так в начале еще нет реализации. Сначала нужно сказать беку что делать. Потом конечно swagger появиться на беке который будет генерироваться из кода. Вопрос, то как передать требования на беке в самом начале, когда дизайн готов и пора проектировать API. Или в вашем случае бек сам смотрит в дизайн и делает API сразу?

Как правильно обжать витую пару?

Спасибо за комментарий, конечно, только тогда когда позволяют условия монтажа. В данном случае сделан ремонт и заводить еще один провод возможности нет.