/cities?q=
и главное, всегда известно какие ендпойнты в какой части приложения дергаются.Кто должен начать разрабатывать APIаналитик
Swagger которые прекрасно работают на небольших проектахон прекрасно работает и на проектах масштаб которых ты плохо себе представляешь
его просто не удобно редактировать и поддерживать в будущемчто именно сложно? из видов ведения документации самый удобный и простой
Сейчас фронты делают отдельный GIT репозитарий, где пишут Swagger через YAML, разбивают все по файлам, потом мы добавляем это в CI и в итоге требования к API публикуютсябред какой то
бы что-то поменять: нужно перейти в репозитарий, закомиттить, дождаться CI и т.д.да, вот из за этого и бред
Может быть полезно?не особо, или надо как то по хитрому продумать. На одном экране может быть куча полей с разными ручками
Сейчас фронты делают отдельный GIT репозитарий, где пишут Swagger через YAMLвсегда вымараживали подобные извраты с переусложнением всего и вся, но такого даже в банках не видел. Телегерам или дискорд же есть для такого, взял и написал, тем более у вас очевидно проект небольшой
Swagger которые прекрасно работают на небольших проектах
он прекрасно работает и на проектах масштаб которых ты плохо себе представляешь
всегда вымараживали подобные извраты с переусложнением всего и вся, но такого даже в банках не видел. Телегерам или дискорд же есть для такого, взял и написал, тем более у вас очевидно проект небольшой
Можно сгенерировать свою спецификацию из аннотаций кода, но говорят, что автоматическая генерация - не лучший подход. Майкл Стоу (Michael Stowe) в статье Беспрепятственный REST: руководство по проектированию Perfect API рекомендует группам вручную реализовать спецификацию, а затем обрабатывать документ спецификации как документ, который разработчики используют при выполнении реального кодирования. Этот подход часто упоминается как «spec-first development».
Spec-first development это философия о том, как разрабатывать API более эффективно. Если вы следуете философии «сначала спецификация», вы сначала пишете спецификацию и используете ее в качестве контракта, к которому разработчики пишут код.
Более 15 000 команд разработчиков программного обеспечения по всему миру используют SwaggerHub. Поскольку спецификация OpenAPI становится в большей степени отраслевым стандартом для документации API, специфичные инструменты SwaggerHub имеют важное значение.
Кто должен начать разрабатывать API: фронтенд или бекенд?
Можно сгенерировать свою спецификацию из аннотаций кода, но говорят, что автоматическая генерация - не лучший подход. Майкл Стоу (Michael Stowe) в статье Беспрепятственный REST: руководство по проектированию Perfect API рекомендует группам вручную реализовать спецификацию, а затем обрабатывать документ спецификации как документ, который разработчики используют при выполнении реального кодирования. Этот подход часто упоминается как «spec-first development».
Spec-first development это философия о том, как разрабатывать API более эффективно. Если вы следуете философии «сначала спецификация», вы сначала пишете спецификацию и используете ее в качестве контракта, к которому разработчики пишут код.
Более 15 000 команд разработчиков программного обеспечения по всему миру используют SwaggerHub. Поскольку спецификация OpenAPI становится в большей степени отраслевым стандартом для документации API, специфичные инструменты SwaggerHub имеют важное значение.
Если, Вы не делали никогда по другому, не значит что этого нет.
Судя по вашим фразам, Вы скорее всего один из них.
Если выше написанное не про вас, не воспринимайте на свой счет, если что-то зацепило - то стоит задуматься.
Поэтому вопрос не в том, что "фронтенд проектирует API и делает это всегда плохо", а в том, что по вашему описанию, вы сейчас руководствуетесь неправильными принципами подходя к проектированию API, это и есть проблема.
/login
часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить например GraphQL им нужно дублировать функционал.Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно?
Можно, а то и нужно, но если вы к этому подойдете с позиции аля "бекенд не знает ничего о приложении" - будет хреново.
у меня где-то написано про такую позицию? Если описание DTO на фронтенл для API вызывает такую реакцию, то у бекенд разработчика проблемы с самооценкой наверное.
То есть в Вашем случае, мы должны ставить задачи беку и прикладывать к ним картинки? По этим картинкам они уже создают API? Фронты пока сидят и ждут когда бэк что-то уже сделает? Получает бек должен хорошо разбираться в дизайне, понимать как работает приложение и т.д. Верно?
В качестве вывода, в Вашем случае фронт все таки не могут предлагать контракт взаимодействия с беком путем написания его в Swagger со последующим обсуждением и правками с бэком?
Что api создаются по картинкам, и если их отдать беку, то что они могут хорошего сделать, если не понимают как работает приложение, т.е. картинки. Только не говорите, что это AgentSmith придумал, что api создаются по картинкам. Вообще, эпичный комментарий, ничем не хуже того, что я про базу писал в ответе.
То есть в Вашем случае, мы должны ставить задачи беку и прикладывать к ним картинки? По этим картинкам они уже создают API? Фронты пока сидят и ждут когда бэк что-то уже сделает? Получает бек должен хорошо разбираться в дизайне, понимать как работает приложение и т.д. Верно?
и если их отдать беку, то что они могут хорошего сделать, если не понимают как работает приложение, т.е. картинки.
Получает бек должен хорошо разбираться в дизайне, понимать как работает приложение и т.д. Верно?
Вся суть вопроса только в этом, не заменить бэк, не отнять у них работу, а оперативно согласовывать API
Но если у меня на картинке (окей, экране интерфейса) список пользователей, я не могу спроектировать к этой области API вместе с DTO (модель, схема данных)?
Это ваша личная оценка, у меня это был как вопрос
"Получает бек должен хорошо разбираться в дизайне, понимать как работает приложение и т.д. Верно?"
Поэтому оценка, что бекенд не может, ваш вывод.
Антон Бреславский, ни проблем, ни негатива. Лишь описание ситуаций, принимать решения вам, нести за них ответственность тоже.
Но если у меня на картинке (окей, экране интерфейса) список пользователей, я не могу спроектировать к этой области API вместе с DTO (модель, схема данных)?
Бизнес логика на беке, сущности в первую очередь создаются там, их взаимодействие тоже, отображение вторично, но можете сделать наоборот
Мне кажется проблема в том, что бекенд разработчики не верно понимают разработку бизнес-логики и разработку интерфейса доступа к ней и к данным. Интерфейс на бекенд может быть HTTP, сокеты ли даже командная строка. Это всего лишь интерфейс. Эти разработчики при проектировании ендпойнта /login
часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить например GraphQL им нужно дублировать функционал.
Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно? Такого кейса нет? Фронты не могут предложить вариант как это видят? Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами. Вы спокойно пойдете делать и они тоже. Потом через какое-то время вы соединитесь и проверите, что ваш контракт выполнен. Что тут не так?
Можно сгенерировать свою спецификацию из аннотаций кода, но говорят, что автоматическая генерация - не лучший подход. Майкл Стоу (Michael Stowe) в статье Беспрепятственный REST: руководство по проектированию Perfect API рекомендует группам вручную реализовать спецификацию, а затем обрабатывать документ спецификации как документ, который разработчики используют при выполнении реального кодирования. Этот подход часто упоминается как «spec-first development».
Spec-first development это философия о том, как разрабатывать API более эффективно. Если вы следуете философии «сначала спецификация», вы сначала пишете спецификацию и используете ее в качестве контракта, к которому разработчики пишут код.
Более 15 000 команд разработчиков программного обеспечения по всему миру используют SwaggerHub. Поскольку спецификация OpenAPI становится в большей степени отраслевым стандартом для документации API, специфичные инструменты SwaggerHub имеют важное значение.
Мне кажется проблема в том, что бекенд разработчики не верно понимают разработку бизнес-логики и разработку интерфейса доступа к ней и к данным. Интерфейс на бекенд может быть HTTP, сокеты ли даже командная строка. Это всего лишь интерфейс. Эти разработчики при проектировании ендпойнта /login часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить например GraphQL им нужно дублировать функционал.
Что скажите? Или API это больше чем данные?
Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно? Такого кейса нет? Фронты не могут предложить вариант как это видят? Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами. Вы спокойно пойдете делать и они тоже. Потом через какое-то время вы соединитесь и проверите, что ваш контракт выполнен. Что тут не так?
Если, Вы не делали никогда по другому, не значит что этого нет?
Есть не только фронты, есть архитектор наконец, и 5 фронт разработчиков.
Есть опытные фронт разработчики и менее опытные бэк, такое может быть.
Гипотеза: если фронты хорошо знают REST, то это реальный профит, когда они сами могут накидать в Swagger ендпойнтов, которые потом утвердит или поправит бекенд. Если добавить сюда удобный редактор в стиле Notion когда тутже правим и видим превью ендпойинта. А если еще к нему зацепить Swagger с реализованного бэка потом и эта чтука сделает кросс-валидацию и скажет где контракт нарушен - то вообще огонь или нет?
К чему это я: НЕТ никакого смысла преждевременно проэктировать АПИ фронту, если финальное слово не за ним. Это трата времени в пустую.
Не понимаю, почему не за ним :-) Оно за всеми, в данном контракте 2 стороны.
Если бэк сделает в API, то, что не нужно фронтам, нафиг такой бэк?
А не из серии: бэк - я так вижу, да будет так, вот вам 1000 полей в пользователе, пофиг что выводить 5 только лишь, а лишние байты зачем?
каркас кода и DTO.
Писать JSON или Swagger - получается только вопрос удобства?
Без ТЗ - результат ХЗ.
про дизайнера - нет. Ни фига не понятно, что он там нарисовал и какая там логика кроется за каждой кнопкой.
Мне кажется проблема в том, что бекенд разработчики не верно понимают разработку бизнес-логики и разработку интерфейса доступа к ней и к данным. Интерфейс на бекенд может быть HTTP, сокеты ли даже командная строка. Это всего лишь интерфейс. Эти разработчики при проектировании ендпойнта /login часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить например GraphQL им нужно дублировать функционал.
Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно? Такого кейса нет? Фронты не могут предложить вариант как это видят? Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами. Вы спокойно пойдете делать и они тоже. Потом через какое-то время вы соединитесь и проверите, что ваш контракт выполнен. Что тут не так?
API это больше чем данные
/get/uuid
и /uuid/get
, для бэка это полная переделка всего кода или костыль с вытягиванием половины базы на каждый запрос.Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами.
Утрируя: для фронта это разница меж /get/uuid и /uuid/get, для бэка это полная переделка всего кода или костыль с вытягиванием половины базы на каждый запрос.
Будет он каждый раз дергать запрос и 1 000 000 строк или сделает слой.
Антон Бреславский, что значит требование заказчика? Это требование было в ТЗ, но архитектура не предусмотрела? Косяк архитектора, как я и написал.
Требования не было в ТЗ? Заказчик идёт нахрен или заключает новый договор на много денег, т.к. данное изменение требует переработки архитектуры. Не вижу ничего необычного.
Будет он каждый раз дергать запрос и 1 000 000 строк или сделает слой.
Оно было изначально.
Есть агрегация сложная, сделай слой и храни в мемкеше.
Если нет хлеба - пусть кушают пирожные.Вы же понимаете, что подобные заявления заставляют меня склоняться на сторону Agent Smith ?)
Кто должен начать разрабатывать API: фронтенд или бекенд?
Конечно, есть Open API и Swagger которые прекрасно работают на небольших проектах. И вопрос, не в том, что Swagger плох, а его просто не удобно редактировать и поддерживать в будущем.
Кто-нибудь видел Swagger в стиле Google Docs или Notion с доступом по ссылке?
Так же к Swagger хотелось бы фичу по привязке областей дизайна к API. Типа выделил область и сказал, тут вызывается /cities?q= и главное, всегда известно какие ендпойнты в какой части приложения дергаются.
Накидали небольшой скетч идеи. Что скажите? Может быть полезно?
Какие данные нужны для бизнес-процесса, и как эти данные будет использовать фронт.
Исходя из этого можно договориться об API.
Реализацией заниматься должны только бэкендеры
Зачем в стиле гуглодоков, когда есть swaggerUI? А доступ по ссылке можно реализовать буквально в пару строчек.
Бэкендеру знать о том, как работает фронт не обязательно.
А как они у Вас договариваются? Сидят рядом, пишут JSON?
Спеку хранить в одном YAML god файле? А как его редактировать совместно?
Верно, ему даже дизайн видеть не нужно, тогда как понять, что нужно сделать? Значит ему должны написать Swagger в любом случае. Как ему его передать? Как потом его актуализировать вместе? Как сравнивать с его Swagger генерируемый из кода?
Если что-то сложное, то вместе сидим, думаем какие будут параметры, и что будет возвращаться.
Кто пишет апи по дизайну, бэк или фронт?
API по дизайну НЕ ПИШУТ!
/news/summary
что бы вывести в виджете в боковой панели кол-во новостей в каждой категории? Экономика - 5, Технологии - 10 и т.д. Откуда бэку знать об этом? Менеджер проекта должен сам это понять и поставить такую задачу? в хорошей команде такие элементарные вопросы даже не обсуждаются. Всё делается на автомате
function getSomething() {
const response = await fetch(...);
const json = await response.json();
return { internalField: json.apiField, internalField2: json.nested.apiField2 };
}
@model()
export class User {
@field({jsonFieldName: 'first_name'})
firstName: string;
}
http.get('/users/1').pipe(map(resp => deserialize(resp, User))
snack_case
, у нас нормальный cameCase
. With SwaggerHub, you can accelerate your team’s design process while enforcing quality and style consistency. The API editor makes compliance with Swagger, now referred to as the OpenAPI Specifications (OAS), simple and intuitive.
Accurate, up-to-date documentation is essential to a successful API initiative. With SwaggerHub, you can generate interactive documentation automatically during design, making it easy for both API consumers and internal users to learn and work with your APIs.
Можно сгенерировать свою спецификацию из аннотаций кода, но говорят, что автоматическая генерация - не лучший подход. Майкл Стоу (Michael Stowe) в статье Беспрепятственный REST: руководство по проектированию Perfect API рекомендует группам вручную реализовать спецификацию, а затем обрабатывать документ спецификации как документ, который разработчики используют при выполнении реального кодирования. Этот подход часто упоминается как «spec-first development».
Spec-first development это философия о том, как разрабатывать API более эффективно. Если вы следуете философии «сначала спецификация», вы сначала пишете спецификацию и используете ее в качестве контракта, к которому разработчики пишут код.
Более 15 000 команд разработчиков программного обеспечения по всему миру используют SwaggerHub. Поскольку спецификация OpenAPI становится в большей степени отраслевым стандартом для документации API, специфичные инструменты SwaggerHub имеют важное значение.