Комментарии 4
Слишком общая статья. Интерпретация/компиляция существующих материалов.
Русский язык такой, что приходится продираться через нагромождение конструкций в поисках смысла. Что мешает быть проще? Вы там в SimbirSoft на таком же языке внутренние доки/артефакты делаете, что ли?
Зачем сначала описывать второй по счёту подход (Code First), а затем первый? Ну так бы и перечислили в нужном порядке
Честно говоря, пока для себя не понял, чем отличается Code First от Design First. В первом случае также есть дизайн контракта API перед кодингом: "An API code first approach doesn’t mean that you won’t have an API design". Попозже поизучаю оригинал )
Статья вводная и дает общее представление тем, кто интересуется темой недавно или ищет, с чего начать погружение. В следующих частях мы подробнее описываем процесс проектирования и разработки по принципам Design Api First — вторая статья вышла сегодня.
При Code First проектирование Api в руках разработчиков backend и генераторов спецификации их программного стека. В зависимости от конкретного генератора спецификация будет отличаться. Если backend на разных языках или команды используют разные генераторы спецификации, результат неидентичен и использовать его в общем случае неудобно. Кроме того, если от этой спецификации зависит frontend или команда автотестирования Api — они ждут, пока программисты backend дадут отмашку.
При Design API First спецификация пишется универсальной (в соответствии с https://spec.openapis.org/, а не как результат работы генераторов). Ее можно, например, использовать параллельно и на frontend и на backend, начинать писать на ее основе контрактные тесты раньше, использовать как первоначальный источник истины/изменений при взаимодействии между несколькими командами и так далее.
Справедливости ради, стоило упоминуть и о минусах Design First. Пусть их в оригинальной статье набралось немного, но всё же - нет большого резона проектировать API, когда нужно быстро построить решение для проверки концепта или сам сервис незамысловатый.
Спасибо за ваше дополнение. Вы правы относительно ProofOfConcept и простых решений. Справедливости ради, это замечание нашло свое отражение в нашей третьей статье о Design Api First (https://habr.com/ru/companies/simbirsoft/articles/746020/). Рациональность и применимость той или иной методологии всегда стоит рассматривать в контексте вашей ситуации. Для нас ее применение обосновано как минимум по двум причинам: разработка итеративна — в контракт вносятся изменения, команды Backend и Frontend работают параллельно
Design API First как паттерн проектирования контрактов межсервисного взаимодействия