Я не могу продумать это все заранее. Комментарий можно пока выбросить из ТЗ. Как бы ладно, бог с ними. Это не бизнес-логика, иэ то можно потом будет допилить как-то.

По поводу остального: я могу предположить. Но глубокого знания Django нет, чтобы вот так сразу все расписать, какими сообщениями ответит бэкенд. Например, картинки будет раздавать nginx. Если он не найдет картинку, я не знаю, как он заорет. Я могу предположить. Но точно не знаю. И то же самое касается любых ошибок на бэке.

вот потому твоя дока ничего не стоит и нужно ждать дев. но даже после этого ты должен будешь предоставить доку на основе уже имеющегося api. (или фронт знает питон и сможет прочитать тесты)

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

А в реальных проектах как делается? Кто готовит доку в сваггере? Ничего себе задачка. Да ее приготовить сложнее, чем бэк написать. Потому что кто же знает заранее-то - какая квалификация нужна.

А в реальных проектах как делается? Кто готовит доку в сваггере? Ничего себе задачка. Да ее приготовить сложнее, чем бэк написать. Потому что кто же знает заранее-то - какая квалификация нужна.

А в реальных проектах как делается? Кто готовит доку в сваггере? Ничего себе задачка. Да ее приготовить сложнее, чем бэк написать. Потому что кто же знает заранее-то - какая квалификация нужна.

Бек готовит доку

ну это в случае code first :)
сейчас популярно design first

У нас кто делает эндпоинт, тот и добавляет его в свагер

и это правильно, имхо ;) у нас было бы так же, если бы был сваггер.. ;)

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

А что у вас?

Стоп, стоп. Мы все слышали, допустим, о смене технологий командами. Ну, допустим, директор объявляет, что завтрп переходим на руби и рельсы. Потому что мы вот тут заказчика нашли и вообще мы теперь рубисты. Это вот запросто может быть. Или новый релиз фреймворка выйдет. Он для всех новый. Так кто же ответственность на себя взять готов - фронт нынче нелегкий. Ошибешься - а там туча человеко-часов переделывать.

ну даже если принять такую ситуацию за реальность(что почти не реально), то я был бы готов принять такую ответственность, и любой другой разраб тоже должен был бы. ибо конкретно вопрос доки/свагера это штука независимая от языка, ну и вообще ответственность это полезно.

Тогда вопрос уже по менеджменту. Тот, кто пишет ТЗ в сваггере имеет самую большую зарплату в команде? Просто он задает темп всей колонне, за все виноватый. Или это все же может быть джун, как выше написано? На самом деле вопрос очень важный, потому что переговоры-то с фронтендером все равно кто-то проводил, когда команда создавалась (если это команда под проект).

Тз в свагере? 😐

Тогда вопрос уже по менеджменту. Тот, кто пишет ТЗ в сваггере имеет самую большую зарплату в команде? Просто он задает темп всей колонне, за все виноватый. Или это все же может быть джун, как выше написано? На самом деле вопрос очень важный, потому что переговоры-то с фронтендером все равно кто-то проводил, когда команда создавалась (если это команда под проект).