1. OpenAPI и Swagger

Архитектурный стиль взаимодействия компонентов распределенной системы к компьютерной сети.

6 разграничений:

  1. Разграничение на клиент и сервер (Client-Server)
  2. Сервер не хранит состояние запроса (Stateless)
  3. Кэширование запросов (Cache)
  4. Единый формат взаимодействия (Uniform Interface)
  5. Слои для управления нагрузкой, балансировкой и масштабированием (Layered System)
  6. Клиент может расширять функциональность за счет загрузки кода с сервера (аплетов или сценариев) (Code-On-Demand) (optional)

RESTful Service — сервис полностью отвечающий архитектурному стилю REST

API DLs — Application Programming Language Description Language — Язык для представления описания интерфесов, понятный и человеку и машинем

Основные языки описания:

  1. Swagger
  2. OpenAPI Specification (OAS)
  3. WSDL (Web Services Description Language) — это язык описания веб-сервисов и доступа к ним, основанный на языке XML.
  4. API Blueprint
  5. RAML (RESTful API Modeling Language)
  6. RSDL (RESTful Service Description Language)
  7. WADL (Web Application Description Language) — машинно-читаемое XML-описание для web-приложений HTTP (как правило, веб-сервисы REST). Аналог WSDL для SOAP.
  8. GCE (Google Cloud Endpoiints)

OpenAPI Specification (OAS) — спецификация интерфейса, не зависит от языка программирования

Swagger

Спецификация+Программа Swagger до версии 3.0 была разработана в 2011 году компанией SmartBear для компании Wordnik (онлайн-словарь английского языка) под лицензией Apache 2.0. В 2015 году переименована в OpenAPI Specification и выложена на GitHub.


Начиная с версии Swagger 3.0 спецификация стала отдельно — OpenApi Spec и отдельно программа Swagger tools

Подходы в разработке:

API Design First

Сначала проектируется интерфейс, а затем разработчики разрабатывают код в соответствии

Code First

Подходит для маленьких интерфейсов

Code First

Code First Аннотации для Java / Kotlin

API Design First

OpenAPI спецификация — описывается в формате yml или JSON

Основные блоки:

Практические советы

  1. Использовать только JSON формат для взаимодействия компонентов (микросервисов)
  2. Для описания Endpoints использовать имена существительные
  3. Для коллекций использовать множественное число
  4. Использовать хлебные крошки — если одна сущность является содержит другую, то путь до эндпоинта вложенной сущности должен быть с указанием сущности в которую она вложена. Например: Инструменты/Электро Инструменты/Шуруповерты/Makita-123
  5. Использовать адекватное ошибок и типы ошибок
  6. Использовать постраничный вывод, фильтрац
  7. Использовать версионирование API

Swagger Framework

  1. Swagger Editor
  2. Swagger UI
  3. Swagger Codegen

Swagger Codegen

Позволяет генерировать из спецификации набор клиентов на различных языках программирования

Swagger Editor

Позволяет создавать и редактировать схему

Swagger UI

Позволяет посмотреть на красивое описание по готовой спецификации и сгенерировать запросы по данной спецификации

Postman

Может сгенерировать коллекцию запросов по OpenApi спецификации

Insomnia

Отображает OpenApi спецификацию, как Swagger Editor

OpenApi Tools

ПО для работы с OpenApi спецификацией

Например Mock Servers — позволяют замокать другие микросервисы для проверки интеграционной разработки локально. Это фековые сервисы — которые дают ваш определенный ответ на ваш определенный запрос.

Проект Pet Store

Проект Pet Store для демонстрации Swagger UI и написания спецификации OpenApi

Swagger Petstore

swagger-petstore GitHub

OpenApi спецификация проекта Pet Store

WireMock Cloud

API First (Contract First) и API Design

API Design — проектируем дизайн, отдаем разработчикам

API First — самое ценное это интерфейс — всё ради того чтобы он был понятен

Источник

В дополнение:

  1. Специфицируй это. Доклад Яндекса
  2. 014. API + Swagger — Игорь Гусев
Оцените автора
Kosenkov.Pro
Добавить комментарий