API это отражение архитектуры. Определённые данные в определённой архитектуре можно получать только определёнными путями.
Утрируя: для фронта это разница меж /get/uuid и /uuid/get, для бэка это полная переделка всего кода или костыль с вытягиванием половины базы на каждый запрос.
Бэк (а точнее Архитектор, но архитектор - всегда как минимум бэк) продумывает архитектуру для оптимального выполнения задачи. От этой архитектуры строится API. Если API не слишком удобно для фронта, но с ним можно жить, это нормально. Если в API не хватает чего-то и это не предусмотрено в архитектуре, но подразумевается задачей - архитектор накосячил и надо всё переделывать(или писать костыли).
Если изменения для удобства фронта вписываются в архитектуру без излишних костылей, но неудобны для бэка - вопрос для обсуждения.
Если изменения для удобства бэка вписываются в архитектуру без излишних костылей, но неудобны для фронта - вопрос для обсуждения.
Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами.
Вы не можете дать добро если сами не знаете. А сами вы не знаете пока не готова архитектура соответствующая задаче. А когда готова архитектура - готово и черновое API. Вот тут вы можете дать добро если оно вписывается. Но этот этап уже сильно позднее начала разработки.
Фронты могут высказать пожелания по API до начала разработки архитектуры или во время, но это именно пожелания, никаких строгих контрактов на этом этапе быть не может, потому что хорошая оптимальная архитектура - это не разок затылок почесать.
Антон Бреславский, у фронта есть дофига чего пилить без бэка. Пока они это напилят - бэк обычно успевает подъехать.)
А формализовать можно, только это выльется в тысячу митингов и пересогласований, пока не устаканится в действительно рабочем варианте. Потому что бэк всё равно так или иначе должен продумать архитектуру, только теперь пытаясь её уродовать, вписывая в бессмысленные требования, взятые с потолка, а не из задачи. Т.е. просто выкидывание времени в трубу и ухудшение конечного результата.
Антон Бреславский, что вы упёрлись в этот дизайн? Дизайн решает задачу, фронт решает задачу, бэк решает задачу. Это всё производное от ЗАДАЧИ. И бэк делает ядро: бизнес логика, хранение, производительность и т.д. и т.п. От бэка зависит всё остальное. Да, даже дизайнеру придётся свой креатив перерисовать, если что-то сделать на бэке по той или иной причине невозможно.
Смапить предоставленный бэком API на дизайн - задача фронта. Если дизайн не расходится с поставленной задачей - API будет подходящим. Если чего-то (удобного в конкретном кейсе) не хватает - задача фронта обсудить это с бэком, я не зря включил этот пункт в ответ.
Антон Бреславский, я фронт, мне нифига не понятно что там дизайнер нарисовал.)
За каждой кнопкой и формочкой скрывается логика. Которая должна быть расписана аналитиком без разночтений.
Это верно для чего угодно сложнее лендинга.
Бэк делает логику. Не api - логику. Api - следствие логики и архитектуры, не наоборот. Сколько раз вам ещё повторить?
Абсолютно бессмысленный. Невозможно придумать (адекватно) архитектуру от API, а не от задачи.
Писать JSON или Swagger - получается только вопрос удобства?
Коротко: да.
Развёрнуто: если б меня лично заставили писать свагер руками я б послал тимлида нафиг. Если настаивали - уволился. Не переношу мартышкин труд. То что может быть автоматизировано - должно быть автоматизировано.
Потенциальная "потеря времени" на мелкие правки и нестыковки простых json-моков, как по мне, куда меньше, чем потеря времени на ручную работу со свагером.
Допускаю, что есть какие-то мега-сложные задачи с мега-сложны API где это было бы оправдано, но я такого не встречал.
Антон Бреславский, не, абсолютно нереален.)
На клиенте из сваггера генерируется просто запросы, а на бэке вы что собрались генерировать? Методы класса? Которые потом бэк должен как-то "заполнить кодом", чтоб оно работало?)
Антон Бреславский, нет никакого "реального времени". Бэк должен сначала продумать архитектуру, условно-целиком в рамках задачи, но точно без пробелов, потом начать реализацию. То что он продумал он может быстро кинуть в виде json либо потратить кучу времени запилив целый сваггер, который в итоге сам потом сгенерируется из его кода.
Т.е. ещё раз: бэк не придумывает API. Бэк придумывает архитектуру, API - это следствие архитектуры. Нельзя придумать API без готовой архитектуры.
Ну, т.е., конечно, можно, но это приведёт к адским костылям и ужасам на бэке, так что лучше не надо.)
Mike, это очень нишевая атака, но суть не в этом. Уязвимости есть во всём. Что бы вы не использовали, нет никакой разницы с TLS: уязвимости находят, их эксплуатируют, их закрывают.
- TLS - дыры ищут гораздо больше народу.
+ TLS - дыры закрывают гораздо быстрее.
Daksin, в следующий раз стоит подумать может eslint дело говорит, прежде чем его отключать.)) Он какбэ именно для этого и существует, а не чтоб тебя раздражать.)
^this
API это отражение архитектуры. Определённые данные в определённой архитектуре можно получать только определёнными путями.
Утрируя: для фронта это разница меж
/get/uuidи/uuid/get, для бэка это полная переделка всего кода или костыль с вытягиванием половины базы на каждый запрос.Бэк (а точнее Архитектор, но архитектор - всегда как минимум бэк) продумывает архитектуру для оптимального выполнения задачи. От этой архитектуры строится API. Если API не слишком удобно для фронта, но с ним можно жить, это нормально. Если в API не хватает чего-то и это не предусмотрено в архитектуре, но подразумевается задачей - архитектор накосячил и надо всё переделывать(или писать костыли).
Если изменения для удобства фронта вписываются в архитектуру без излишних костылей, но неудобны для бэка - вопрос для обсуждения.
Если изменения для удобства бэка вписываются в архитектуру без излишних костылей, но неудобны для фронта - вопрос для обсуждения.
Вы не можете дать добро если сами не знаете. А сами вы не знаете пока не готова архитектура соответствующая задаче. А когда готова архитектура - готово и черновое API. Вот тут вы можете дать добро если оно вписывается. Но этот этап уже сильно позднее начала разработки.
Фронты могут высказать пожелания по API до начала разработки архитектуры или во время, но это именно пожелания, никаких строгих контрактов на этом этапе быть не может, потому что хорошая оптимальная архитектура - это не разок затылок почесать.