Что такое first api
Разработка Spring Boot-приложений с применением архитектуры API First
В этом материале я приведу практический пример реализации архитектуры API First с применением спецификации OpenAPI. А именно, сначала расскажу о том, как создал определение API, а затем — о том, как, на основе этого определения, создал серверную и клиентскую части приложения. В процессе работы у меня возникли некоторые сложности, которых я тоже коснусь в этом материале.
Преимущества архитектуры API First
По мере того, как всё сильнее распространяется подход к разработке приложений, основанный на микросервисах, определённую популярность набирает и архитектура API First. У этой архитектуры имеется довольно много сильных сторон.
▍Чёткое определение контрактов
Благодаря применению архитектуры API First можно создавать точные определения контрактов, которые позволяют чётко описывать возможности, которыми должны обладать приложения. Эта архитектура, кроме того, помогает отделять интерфейс системы, предоставляемый внешним пользователям посредством API, от деталей реализации возможностей этой системы.
▍Хорошее документирование API
Применение архитектуры API First способствует тому, что разработчик, создавая API, следует правилам, изложенным в хорошо структурированной, понятной документации. Это помогает тем, кому нужно работать с API, обрести чёткое понимание особенностей интерфейса, который представлен этим API.
▍Создание благоприятных условий для распараллеливания работы над проектами
Это — одна из моих любимых возможностей, получаемых тем, кто применяет архитектуру API First. Если в проекте имеется чёткое описание API, то тот, кто занимается разработкой самого API, и тот, кто пользуется возможностями этого API, могут работать параллельно. В частности, пользователь API, ещё до того, как сам API готов к работе, может, основываясь на уже согласованных контактах, создавать моки и заниматься своей частью работы над проектом.
Теперь, когда мы обсудили сильные стороны архитектуры API First, перейдём к практике.
Практика использования архитектуры API First
Я начал работу с посещения ресурса, дающего доступ к Swagger Editor, и с создания определения моего API. Я, при описании API, пользовался спецификацией OpenAPI 3. Определения API можно создавать и с применением многих других инструментов, но я выбрал именно Swagger Editor из-за того, что у меня есть опыт создания документации для Java-проектов с использованием этого редактора. Swagger Editor мне нравится и из-за того, что он поддерживает контекстно-зависимое автодополнение ввода ( Ctrl + Пробел ). Эта возможность очень помогла мне при создании определения API.
Правда, я не могу сказать, что свободно владею техникой определения API, поэтому я, описывая свой API, опирался на пример petstore.
Для начала я создал весьма минималистичное определение API, описывающее создание учётной записи пользователя системы с использованием POST-запроса.
Генерирование кода
После того, как подготовлено определение API, можно заняться созданием сервера и клиента для этого API. А именно, речь идёт о Spring Boot-приложении. Обычно я создаю такие приложения, пользуясь Spring Initializr. Единственной зависимостью, которую я добавил в проект, стал пакет Spring Web.
После этого я воспользовался Maven-плагином OpenAPI Generator, который позволяет создавать серверный и клиентский код.
▍Генерирование серверного кода
Содержимое конфигурационного файла для генерирования серверного кода
Среди настроек, которые я внёс в этот файл, хочу отметить указание имени пакета, которое будет использоваться при создании классов API и модели. Тут, в общем-то, имеется довольно много настроек, полное описание которых можно найти здесь. В частности, в подобном файле можно задать префикс имён классов модели
Коду, который генерируется плагином, нужны ещё несколько зависимостей, обеспечивающих его успешную компиляцию. Мне удалось найти минимальный набор таких зависимостей:
А теперь — самое интересное: генерирование кода. После выполнения команды mvn clean verify в нашем распоряжении оказываются несколько классов, сгенерированных плагином.
Результат работы генератора серверного кода
Теперь сервер готов к работе, а значит — пришло время поговорить о клиенте.
▍Генерирование клиентского кода
Содержимое конфигурационного файла для генерирования клиентского кода
Нам, кроме того, понадобятся дополнительные зависимости:
Результат работы генератора клиентского кода
После того, как код будет сгенерирован, в нашем распоряжении окажутся классы, позволяющие организовать взаимодействие клиента с сервером. Тут же имеются и реализации механизмов базовой аутентификации.
На этом работа над клиентской частью проекта завершена. Теперь можно проверить совместную работу клиента и сервера.
Проблемы, выявленные в ходе реализации проекта
В последней версии плагина (5.0.1), которой я и пользовался, имеются некоторые проблемы.
В этом репозитории вы можете найти код проекта, который мы обсуждали.
Применяете ли вы в своих проектах архитектуру API First?
Разработка REST API — что такое Code First подход?
Это четвертая статья в серии статей по REST API:
Разработка хорошего REST API важна для того, чтобы иметь хорошие микросервисы. Подход Code-First фокусируется на генерации контракта из кода. Это наилучший из возможных подходов?
Вы изучите
Что такое Code-First подход?
Всякий раз, когда вы разрабатываете сервис, такой как REST API или SOAP API, вы можете выбрать один из двух подходов:
Spring Boot Code First пример REST API
Мы разрабатываем RESTful веб-сервис, используя Spring Boot Framework для генерации API. Например, в API retrieveAllUsers () мы открываем URI «/users» и
возвращаем всех пользователей (ресурс /users),
вызывая метод сервиса.
Когда мы переходим на этот URL, мы возвращаем всех пользователей:
Аналогичным образом определены и другие сервисные методы, каждый из которых имеет свой собственный URI. В этом примере мы берем код и генерируем из него документацию. В этой документации указано, как пользователь может использовать сервис. Для этого мы используем формат документации Swagger:
Swagger позволяет нам генерировать документацию из кода. Например, вот что Swagger генерирует для запроса на получение всех пользователей:
Он выводит тип получаемого нами ответного сообщения и сопровождающий его статус ответа. Вы даже можете вызвать этот сервис из Swagger получить ответ:
Вы также можете отправить запрос POST в «/users«:
Swagger сообщит нам, как структурировать сообщение запроса и указать внутри него отдельные форматы полей. Он также сообщит вам тип ответа, который вы получите, вместе с кодом ответа. То, что Swagger генерирует из кода, называется контрактом.
Преимущества Code First
Основные преимущества этого подхода:
Недостатки Code First
Недостатки этого подхода заключаются в следующем:
Нет параллельной разработки
Производитель услуг и потребители услуг не могут разрабатывать параллельно. Сначала необходимо разработать сервис, затем сгенерировать контракт, и только после этого можно написать код потребителя, который будет придерживаться контракта. Без понимания контракта потребитель не может быть разработан.
Нет цели для команд
Поскольку договор не может быть известен до того, как сервис будет разработан, не существует цели для различных заинтересованных сторон в разработке. Следовательно, есть все шансы, что направления будут отклоняться, и будут внесены ненужные изменения, что приведет к напрасной трате усилий.
Нет кроссплатформенной совместимости
На некоторых старых платформах не так просто сгенерировать контракт из кода. В результате этого для сгенерированных контрактов довольно часто возникает несовместимость между платформами.
По этому вопросу имеется авторское видео.
Резюме
В этой статье мы исследовали Code First подход построения REST API. Несмотря на то, что подход, основанный на коде, эффективен с точки зрения разработчика, он сталкивается с серьезными проблемами, когда речь идет о совместной разработке поставщика и потребителя.
От API first на Swagger до Single contract на RAML
Ты наверняка знаешь, что такое API интерфейсы и то, как много от них зависит в твоем проекте. Более того, я так же полагаю, что ты уже знаком с тем, что такое API first подход и знаешь, что Swagger и его Open API являются одними из самых популярных инструментов, помогающих ему следовать.
Но в этой статье я хочу рассказать про подход к реализации API first, концептуально отличающийся от того, что предлагает Swagger и Apiary. Во главе идеи стоит понятие Single contract и возможность его реализации на базе RAML 1.0.
От API first на Swagger до Single contract на RAML
При проектировании современных программных систем часто встает задача согласования и разработки интерфейсов для взаимодействия их компонентов друг с другом. В последнее десятилетие огромную популярность и развитие получили SPA и thick мобильные приложения взаимодействующие с сервером через API интерфейсы. Если раньше разработка интерактивного веб сайта происходила путем поэтапных правок кода серверной стороны для генерации HTML разметки с ее последующей передачей браузеру клиента, то теперь разработка динамических веб приложений сместилась в сторону создания единого API сервиса и параллельной разработки множества приложений (в том числе и SPA) работающих с этим API как с главным источником данных. Такой подход позволяет более удобно разделять задачи, организовывать команды, специализирующиеся только на конкретных технологиях (привлекать более узконаправленных специалистов), организовать параллельную разработку на самых первых этапах, а также позволяет создать единую точку коммуникации — API интерфейс.
Такая единая точка коммуникации требует формального и однозначного определения, этим документом является API спецификация. Для разработки и документирования API спецификаций сегодня применяются различные технологии и языки, например: OAS (Swagger), Apiary и RAML.
Следующие три пункта определяют природу API first подхода:
Single Contract. Контрактные инструменты и библиотеки
Термин Single contract не претендует ни на какое участие в критике за его использование в тексте статьи. Его применение, в данном контексте, является лично моей идеей.
Расширение понятия API first, до более общего Single contract позволяет рассматривать API-спецификацию не только как формальное описание интерфейса взаимодействия между компонентами системы, но и как единый контракт, используемый любым количеством внешних библиотек и инструментов в качестве источника конфигурации. В таком случае, эти инструменты и библиотеки можно воспринимать как клиенты контракта наравне со SPA или мобильными приложениями. Примерами таких клиентов могут быть:
Swagger (OAS) как инструмент описания Single contract
Существующие наиболее популярные на рынке Swagger (OAS) и Apiary (Blueprint) позволяют описывать HTTP API интерфейсы, используя специальные языки: Open API на базе YAML или JSON, Blueprint на базе Markdown, что делает спецификации легко читаемыми. Также существует множество инструментов и библиотек, созданных большим open-source сообществом. Swagger на данный момент широко распространен и, можно сказать, стал де-факто стандартом API first. Многие внешние системы поддерживают импорт Swagger спецификаций, например SoapUI, Readme.io, Apigee и т.д. Кроме того, существующие SaaS Swagger Hub и Apiary позволяют пользователям создавать проекты, загружать или создавать свои спецификации, пользоваться встроенными генераторами документации и mock-серверами, а также публиковать ссылки для доступа к ним извне.
Swagger вместе с его OAS 3.0 выглядят довольно уверенно и его функционала для описания API (особенно простого) хватает в большинстве случаев. Далее приведен список плюсов и минусов Swagger:
Например, реализация «умного» mock api server требует больше информации, чем способен дать документ спецификации, именно поэтому встроенный в Swagger Hub mock API способен только на генерацию фейковых данных на основе типов данных/структур, полученных из документа спецификации. Несомненно, этого мало и такая функциональность mock-сервера может удовлетворить лишь несложный API клиент.
В нашей компании, в ходе разработки одного из проектов (React SPA + API server), потребовался следующий функционал mock-сервера:
Если инструментов, работающих в окружении процесса разработки по такому принципу, будет больше чем один mock-сервер, то мы получим “зоопарк” инструментов, каждый из которых, при наличии своего уникального функционала, вынужден иметь свой уникальный файл конфигурации, логически привязанный к базовой API-спецификации, но фактически расположенный отдельно и живущий “своей жизнью”.
Проблема: разработчик будет вынужден поддерживать актуальность всех конфигураций вслед за изменением версий базовой спецификации, зачастую в совершенно разных местах и форматах.
Некоторые примеры сервисов, работающих по схожему принципу:
RAML, annotations, overlays
Стремление найти инструмент, исключающий ранее указанное ограничение OAS, позволяющий рассматривать спецификацию как единый контракт для всех клиентских инструментов, привело нас к знакомству с языком RAML. Про RAML достаточно написано, можно прочитать, например, здесь https://www.infoq.com/articles/power-of-raml. Разработчики RAML попытались заложить в язык поддержку модульности на уровень его концепции. Теперь каждая компания или индивидуальный разработчик может создавать свои или использовать уже готовые публичные словари при проектировании API, переопределять и наследовать уже готовые модели данных. Начиная с версии 1.0 RAML поддерживает 5 различных типов внешних модулей: include, library, extension, trait, overlay, что позволяет применять каждый из них в зависимости от задачи максимально гибко.
Пришло время обсудить главную возможность RAML, которая, по не совсем понятным причинам, не имеет аналогов в OAS и Blueprint — Annotations.
Annotations в RAML — это возможность прикрепления пользовательских метаданных к базовым структурам языка.
Именно эта функция RAML и стала поводом для написания этой статьи.
Сами структуры пользовательских аннотаций должны иметь четкие описания на языке RAML. Для этого используется специальная секция annotationTypes, определения из которой, также можно вынести во внешний модуль. Таким образом, появляется возможность определения специальных параметров внешнего инструмента в виде аннотаций, привязанных базовому определению API RAML. Во избежание захламления базовой спецификации огромным количеством аннотаций для различных внешних инструментов, имеется поддержка возможности их выноса в отдельные файлы — overlays (а можно и в extensions), с классификацией по области применения. Вот что сказано про overlays в документации к RAML (https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#overlays):
An overlay adds or overrides nodes of a RAML API definition while preserving its behavioral, functional aspects. Certain nodes of a RAML API definition specify the behavior of an API: its resources, methods, parameters, bodies, responses, and so on. These nodes cannot be changed by applying an overlay. In contrast, other nodes, such as descriptions or annotations, address concerns beyond the functional interface, such as the human-oriented descriptive documentation in some language, or implementation or verification information for use in automated tools. These nodes can be changed by applying an overlay.
Overlays are particularly important for separating interface from implementation. Overlays enable separate lifecycles for the behavioral aspects of the API that need to be controlled tightly, such as a contract between the API provider and its consumers, versus those needing little control, such as the human- or implementation-oriented aspects that can evolve at different paces. For example, adding hooks for testing and monitoring tools, appending metadata relevant to a registry of APIs, or providing updated or translated human documentation can be achieved without changing any aspects of the behavioral aspects of the API. These things can be controlled through a rigorous version and change management process.
Другими словами, данный функционал позволяет “отделять зерна от плевел”, например, основное описание API-спецификации, от дополнительной метаинформации специфичной для конкретного инструмента использующего ее для работы. Метаинформация в каждом отдельном оверлее “навешивается” на различные блоки спецификации в виде аннотаций.
Пример базовой структуры:
В результате появляется возможность реализации единого контракта: вся функциональная, поведенческая и метаинформация хранится и версионируются в одном едином месте, а контрактные инструменты — клиенты контракта, должны иметь поддержку используемых аннотаций в данной спецификации. С другой стороны, именно сами инструменты могут предъявлять собственные требования к аннотациям, которые необходимо “навесить” на спецификацию — это обеспечит более широкий круг возможностей при разработке контрактных инструментов.
Вышеизложенная концепция изображена на рисунке ниже:
Среди минусов данного подхода можно выделить высокую сложность ручной синхронизации файла базовой спецификации и каждого из оверлеев: при обновлении структуры базовой спецификации, нужно применить требуемые изменения в структурах оверлеев. Эта проблема становится более серьезной при появлении более чем одного оверлея.
Возможным и самым очевидными решением будет разработка специального редактора или дополнения для существующего онлайн редактора RAML https://github.com/mulesoft/api-designer. Область редактирования остается неизменной, но появляется возможность создания табов: каждый новый таб является окном для редактирования закрепленного за ним оверлея. При редактировании базовой структуры спецификации в основном окне, меняются также структуры во всех созданных табах, а при обнаружении несовместимости новой структуры с уже существующими аннотациями размещенных в табах-оверлеях появляется предупреждение. Более детальное рассмотрение такого редактора является отдельной темой и заслуживает серьезного обдумывания.
Существующие наработки
В ходе поиска существующих решений, близких к реализации идеи использования аннотаций как средства описания метаинформации, были найдены следующие решения:
Проблемы RAML
Несмотря на функциональность, прогрессивность базовой идеи, внимания со стороны крупных производителей программного обеспечения (cisco, spotify, vmware и т.д.), на сегодняшний день RAML имеет серьезные проблемы, которые могут стать фатальными относительно его успешной судьбы:
Концептуальные разногласия. Первое заключение
We call information that describes available resources types, their behavior, and their relationships the resource model of an API. The resource model can be viewed as the RESTful mapping of the application data model.
В RAML application data model это типы объявленные в блоке types, а resource model of an API — это то, что описывается в блоке resources RAML. Следовательно, необходимо наличие возможности описания этого mapping. Но текущая реализация RAML позволяет сделать такой mapping только 1 к 1, то есть, использовать types “как есть” внутри объявления API ресурсов.
Я считаю это самой главной проблемой языка, решение которой, позволит RAML выйти за рамки API definition language и стать полноценным model definition language: более общим языком (нежели чем OAS или Blueprint) используемым для описания единых контрактов систем, по сути своей, являющихся формальным ядром множества их компонентов.
Выше перечисленное делает RAML слабым игроком, который в данный момент не способен выиграть конкурентную борьбу у Swagger. Возможно, именно поэтому в результате главный разработчик RAML пошел на кардинальные меры https://blogs.mulesoft.com/dev/api-dev/open-api-raml-better-together/
Идея Single contract RAML SaaS
Базируясь на понятии Single contract, отталкиваясь от идеи хостинга API спецификаций Swagger hub на основе OAS, а также полагаясь на возможности RAML объявления метаинформации и разделения базовой спецификации при помощи оверлеев, напрашивается идея альтернативного SaaS решения для хостинга и управления спецификациями на основе языка RAML которое способна превзойти Swagger Hub и Apiary объемом и качеством возможного функционала.
Новый сервис, по аналогии со Swagger hub, будет являться хостингом пользовательских контрактов с предоставлением онлайн редактора и возможности просмотра документации-превью с обновлением в реальном времени. Главным отличием должно стать наличие встроенного в сервис каталога контрактных плагинов, любой из которых, пользователь сможет установить в своей текущий проект API-спецификации. Для установки будет требоваться реализовать требуемые RAML аннотации указанные в документации к плагину. После добавления нового плагина в проект, в окне редактора кода добавится новый таб при переключении на который, станет доступным редактирование аннотаций установленного плагина. Структура базовой спецификации должна автоматически дублироваться во все табы соответствующие плагинам. При возникновении конфликтов между базовой структурой и уже существующими аннотациями специальный механизм должен предложить варианты его решения, либо разрешить автоматически.
Технически каждый таб будет являться абстракцией над RAML overlay содержащим аннотации каждого конкретного плагина. Этим гарантируется совместимость спецификации с любым инструментом поддерживающим RAML 1.0.
Каталог плагинов должен быть открытым для расширения open source сообществом. Также возможна реализация платных плагинов, что может послужить стимулом для разработки новых.
Возможные плагины: API документация с поддержкой большого количества аннотаций для гибкой параметризации ее рендеринга, “умный” mock сервер (из примера выше), скачиваемые библиотеки для валидации запросов или кодогенерации, средства отладки исходящих запросов API для мобильных приложений (caching proxy), нагрузочные тесты с настройкой flow тестирования через аннотации, различные плагины для интеграции с внешними сервисами.
Данная идея сервиса содержит явные преимущества перед существующими сервисами для управления API-спецификациями и ее реализация закладывает начало возможного изменения подхода к имплементации любых внешних систем так или иначе связанных с API.
Второе заключение
Целью этой статьи не является критика Swagger, Apiary или других де-факто стандартных инструментов для разработки API, а скорее рассмотрение концептуального различия c подходом к проектированию спецификаций продвигаемым RAML, попыткой введения понятия Contract first и рассмотрения возможности его реализации на базе RAML. Другой целью явилось желание привлечь к RAML вполне заслуженного внимания разработчиков для дальнейшего возможного развития его сообщества.
API First архитектура или рассуждения на тему: толстый сервер против тонкого
Доброго времени суток всем хабражителям. Меня зовут Илья Шакитько и я работаю в LeaseWeb, в команде, работающей над облачными сервисами. Решая очередную задачу, связанную с исследованием той или области, мы стараемся поделиться полученными знаниями или мыслями с сообществом. Не так давно мы проводили DevOps встречу в нашем офисе, где одним из выступающих был мой коллега, Мауритс ван дер Скхи, который рассказывал об API First архитектуре. Немногим ранее в нашем блоге он опубликовал статью, переводом которой я хотел бы поделиться с вами.
Введение
Повторное использование кода в MVC
MVC архитектура уже давно популярна. В 2004 году ее популярность стремительно выростает с выходом Ruby on Rails. MVC парадигма позволяет вам наиболее эффективно использовать существующий код, если это — front-end / back-end приложение (в виде CMS), в котором пользователи используют front-end, а сотрудники — back-end. В этом случае вам потребуется выбрать одинаковый стек ПО для front-end и back-end и сделать эти приложения максимально похожими. Когда стратегия MVC применяется правильно, вы можете повторно использовать код многих частей приложения. Ими могут быть, например, DBAL/ORM, Бизнес-логика, Представление и AAA (Аутентификация, Авторизация и Учет(Accounting). В частности с AAA сотрудники могут использовать ту же форму входа, что и клиенты, и обе формы будут иметь общий код.
Мобильные представления для MVC
В 2007 году Apple представляет iPhone, и необходимость корректного отображения веб-приложений (и сайтов) на маленьких экранах быстро вырастает. MVC приложения были и до сих пор остаются наиболее подходящими для адаптации под маленькие экраны. Все, что необходимо — отдельный или доработанный набор представлений для отображения на смартфоне или планшете. Стратегия создания набора представлений для мобильных и десктоп устройств называется “mobile first“. Это наиболее экономически выгодный и радикальный подход, требующий лидерства и принятия решений, т.к. любое программное обеспечение нуждается в таком драматическом изменении, как доработка всех представлений. Альтернативой этому может быть поддержка двух наборов представлений: одного для мобильных устройств, другого для десктоп. Эти представления часто размещают на “m.” поддоменах. Это простой и прозрачный подход.
Добавление API к MVC
В сфере разработки приложений сейчас все спорят на тему «HTML5 vs Native». Я бы процитировал здесь Дэнни Брауна:
Любой компании, создающей мобильные приложения сегодня, приходится выбирать: делать Нативное или HTML5 приложение. Оба варианта имеют свои преимущества и недостатки, но неправильный выбор может дорого стоить. – Дэнни Браун
Выбор нативного приложения потребует от вас создать полный, адаптивный и хорошо документированный API, в то время как выбор HTML5 влечет за собой изменение всех представлений в приложении. Есть много аргументов в пользу любого из вариантов, и всегда решение, что лучше, а что нет, зависит от ситауции. Но есть один подход, который будет всегда провальным: создание API как представление в MVC. Позвольте мне объяснить, почему он провальный и почему так много людей все равно используют его.
Обычно, когда сервер использует MVC парадигму, время загрузки страниц составляет 200мс. Функции сервера: абстракция БД, бизнесс логика и представление. Вот почему он также называется «толстый сервер». API First сервер не отвечает за представление, содержит меньшую бизнес-логику на запрос и потому называется «тонкий сервер». Хороший API сильно оптимизирован под скорость выполнения, которая обычно достигает 20мс. Т.е. за время загрузки страницы для мобильного устройства (к примеру, 300мс) можно сделать до 10-и API вызовов.
До сих пор, когда кто-то выбирает MVC и теперь нуждается в API, наиболее простой вещью будет добавить несколько представлений, которые возвращают JSON и назвать это «RESTful API». И все, что вам останется сделать, это написать немного документации, и ваш начальник будет счастлив. Фактически же, такой API абсолютно непригоден для использования в реальной жизни, потому что он не масштабируемый и ужасно медленный. Это действительно почувствуется, когда API будет уже долго использоваться и назад пути не будет.
Твиттер и API first
В 2010 году Твиттер анонсировал «API First» стратегию. Они создали JavaScript веб-приложение на схожей архитектуре с мобильными приложениями и назвали ее Javascript архитектура. Это позволило им полностью использовать их же API. Раньше API был дополнением к веб-приложению, но теперь он стал основой разработки всех других продуктов. API Твиттера сфокусирован на предоставлении оптимальной интеграции для JavaScript программистов по средством RESTful JSON API. Но они также поддерживают и традиционные страницы:
В целях поддержки crawlers и пользователей без JavaScript нам необходима система рендеринга, которая будет запускаться и на сервере, и на клиенте. – Твиттер
Такой подход предоставления традиционных страниц при параллельном использовании «API First» стратегии я бы назвал «Гибридным». В диаграмме ниже я попытался перечислить различные подходы.
Заключение
Оптимальное использование кода снижает расходы, но достичь этого можно только при наличии сильной архитектурной стратегии, которой вы будете следовать. Рефакторинг кода для соответствия API First архитектуре не принесет прибыли напрямую. Он снизит стоимость последующих изменений, несомненно, но уровень доверия, необходимый для принятия такого решения, не так просто получить.
Материалы для чтения
Это уже не первая статья об API First архитектуре. Если вам интересно узнать больше, предлагаю ознакомиться с материалами, представленными ниже (источники на английском языке):