Комментарии 11
Ирония в том, что этот подход не что иное, как воплощение классических этапов разработки, о которых всё время твердят олды, но шарахаются Agile адепты: проектирование и системный анализ.
На практике именно так. Четкая спецификация API позволяет бустануть разработку в разы, автоматизировать некоторую деятельность, увеличить качество и стабильность софта.
Я бы еще добавил, что наличие генерируемых интерфейсов для сервера не гарантирует вам что они будут реализованы. Поэтому на сервере можно добавить механизм, который будет явно верифицировать спеку и реализованный бэкенд.
Любой API фреймворк фактически регистрирует все модели и роуты, достаточно привести это к формату вашей спеки и сравнить. Так на продакшене точно не окажется сервис, который реализует заявленный API не полностью.
Это особенно актуально для динамических языков типа Python.
Не совсем. Agile не отрицает написание документации перед выполнением самой задачи. Как раз при использовании agile фреймворков и возникают разлады с несогласованными протоколами общения из-за частых изменений и релизов. Подход как и раз и позволяет держать единый формат спецификации.
Не отрицает, я под Agile адептами имел в виду некоторый собирательный образ мейнстримового IT менеджера, для которого проектирование API звучит как саботаж эффективной работы, как призыв к "устаревшим" моделям управления разработкой.
А по сути нет никакого "API-First" подхода. Есть рациональный и давно известный подход — сначала анализируешь, проектируешь, затем реализуешь. И это даёт все перечисленные в статье преимущества.
Просто в один момент отрасль поразила идея, что для эффективной разработки можно только "обсудить на митинге", а всё остально табу. Вот и приходится уже существующие практики и опыт преподносить по новому, придумывать новые названия, лишь бы не пугать тех самых менеджеров.
Конечно, использование подхода не гарантирует наличие имплементации. Это гарантирует процесс тестирования (который в этом случае начинается рано - сразу после разработки спецификации). Если уж на продакшн попал не реализованный метод API, то скорее всего, он мало приоритетный. На мой взгляд, это всё равно лучше, чем если бы на продакшн сервисе оказался неверно имплементированный метод или несовпадение со спецификацией.
На мой взгляд, это всё равно лучше, чем если бы на продакшн сервисе оказался неверно имплементированный метод или несовпадение со спецификацией.
Так я же не отрицаю. Это я к тому, что не все языки как Java умеют гарантировать соответствия интерфейса реализации. Поэтому, если надо, можно использовать формальность API спеки и реализовать проверку в более общем виде. Это еще одно преимущество API-First.
Надо еще все API всех проектов сложить в одну репу. Туда же - генерацию кода с DTO и билд библиотек для используемых платформ. Туда же - документацию. И все это - через MR и ревью всех пользователей.
Подобные "озарения" посещают людей регулярно - только почему-то они каждый раз выдумывают что-то несовместимое с прошлой версией. То, что вы предлагаете - называется "interface definition language" - в Sun RPC 80х годов это был XDR, в CORBA 90х и DCOM 2000х - IDL, в 2010х царил WSDL (для "продвинутых" - ProtoBuf) - плюс еще где-то 30 более нишевых или не получивших популярность форматов.
Вот уж действительно - индустрия бегает по кругу, только с каждой итерацией потребление ресурсов растет...
API-First и микросервисы