Была ли договоренность об описании модели и запросов к Backend в проекте

А, слушай, вот эта тема про договорённости между фронтом и беком — это вообще святое, пиздец как важно. Потому что без этого начинается натуральный пиздец, когда один пишет одно, другой ожидает другое, а в итоге всё падает с ошибками, и все орут, как суки.

Так вот, в нормальных, не ебучьих проектах, обычно договариваются через какие-то инструменты, чтобы не было вот этого «на словах».

Во-первых, классика жанра — это Swagger, он же OpenAPI. Это когда бекенд, такой красавчик, выкладывает специальную страничку, где всё расписано: вот эндпоинт /api/users, вот чтобы к нему обратиться, нужно вот такой JSON в рот ему запихнуть, а в ответ он тебе, сука, выплюнет вот такой объект. И все модели, все поля — всё как на ладони. Просто сказка, а не жизнь.

User:
  type: object
  properties:
    id:
      type: integer
    name:
      type: string
    email:
      type: string

Смотри, вот описание юзера. Прям видно — id число, name строка. Никаких «ой, а я думал там массив». Нет, блядь, думать не надо, всё написано.

Во-вторых, если проект модный и у них там GraphQL. Тут вообще отдельная песня. Там есть схема, этакая библия всего, что можно спросить и что в ответ получить. Типизировано всё до нельзя, фронтендер может как слепой котёнок на ощупь собрать запрос и быть уверенным, что не сломается. Красота, ёпта.

Ну и в-третьих, бывает такое дикое — Postman коллекции. Бекенд-разработчик, такой мужик с бородой, просто скидывает файлик: «На, хуле, вот тебе все запросы, которые я поддерживаю. Импортируй и тыкай». Примитивно, но работает, если всем похуй на изящные решения.

А теперь главное, что они там, эти команды, должны между собой согласовать, чтобы не было потом волнения ебать и криков «это не мои баги!»:

• В каком формате данные летают? JSON? XML? Да похуй, главное договориться. А то один JSON шлёт, а второй ждёт XML — и привет, ебаный стык.
• Какие статус-коды ошибок? Что такое 404? А что такое 418 — «Я чайник»? Шутка, но суть ясна. Чтобы фронт знал, если пришло 500, то это пиздец на сервере, а если 400 — то он сам мудак и криво запрос составил.
• Как пагинация работает? limit и offset? Или page и size? Чтобы не получилось, что фронт просит «дай 10 записей», а бек возвращает все 10 тысяч и кладет ему на процессор.
• Как фильтровать и сортировать? Чтоб можно было сказать «дай мне пользователей по имени А, отсортированных по дате». А не костылять на фронте, выгрузив всю базу.
• Версионирование API. Это чтобы можно было всё сломать и выпустить v2, а старые клиенты на v1 ещё работали и не орали. Без этого — прямой путь в ад, когда одно изменение на беке ломает прод.

Короче, если нет чёткого соглашения — это не проект, а рулетка. Один пишет, второй гадает, а в продакшене всё горит синим пламенем. Так что, блядь, договаривайтесь, суки, на берегу!