В общем, после новинок от OpenAPI Initiative, набор стандартов, языков и спецификаций в области интеграций выглядит совсем уж запредельно 🤯
Итак, что вам нужно знать, чтобы разбираться в интеграциях в 2024:
🔲 JSON — язык разметки, чтобы читать и писать тела запросов и ответов в вызовах API
🔲 JSON Schema — чтобы описывать структуру JSON и валидировать документы
🔲 RegEx (ECMA-262) — чтобы задавать ограничения на формат для строковых полей
🔲 HTTP/1.1 — базовый протокол, нужно хотя бы понимать структуру запроса (метод, домен, путь, параметры, заголовок, тело, ошибки)
🔲 YAML — язык разметки для чтения и составления спецификаций OpenAPI
🔲 OpenAPI — собственно, стандарт для описания REST-подобных API.
🔲 XML, XSD — если вы работаете с государственными сервисами
🔲 WSDL — если у вас есть интеграции через SOAP
🔲 AsyncAPI — если у вас есть асинхронные интеграции, брокеры сообщений, очереди. Между прочим, уже версия 3.0.0 вышла, зрелый продукт!
🔲 AVRO — формат данных, часто использующийся в Kafka. Схема AVRO может быть включена в спецификацию AsyncAPI
🔲 OAuth 2.0 — протокол аутентификации авторизации
Про что нужно знать, что они есть, и рассматривать при необходимости:
🔲 Protobuf — формат данных gRPC, также может использоваться в Kafka, схему можно включить в AsyncAPI
🔲 JSON-RPC — легковесный формат вызова удаленных процедур через HTTP
🔲 GraphQL — формат описания схемы данных и язык запросов
🔲 TypeSpec — легковесный формат описания API, из которого генерируется спецификация OpenAPI (вот это я бы рекомендовал посмотреть — объем документа там в разы меньше, чем у OpenAPI)
🔲 XSLT — если вам приходится преобразовывать документы XML
🔲 JSLT или JSONata — как XSLT, но для JSON: языки запросов и преобразований
🔲 JSONPath — язык запросов к документу JSON
Для продвинутых и тех, кто занимается управлением API:
🔲 Модель OSI или TCP/IP — что происходит в сети на уровнях ниже HTTP
🔲 HAL — формат сообщений JSON, если вы хотите больше следовать принципам HATEOAS из REST
🔲 JSON:API — стандарт на формат сообщений (тоже в русле идей HATEOAS) и некоторые принципы формирования запросов
🔲 API Design Systems — язык спецификации правил для построения API (можно валидировать любое API в компании)
🔲 RFC 9457 — спецификация детального описания ошибок в ответах HTTP
🔲 JSON-Patch, JSON-Merge — форматы описания изменений документа JSON, то, что должно отправляться в команде PATCH
🔲 Overlay — спецификация изменений в документ OpenAPI
🔲 Arazzo — спецификация последовательности (воркфлоу) вызовов нескольких API
Вот, приятного чтения на каникулах 🙂 Специально поставил иконку пустого чек-бокса — можете мысленно отметить, что из этого вы уже знаете и с чем работали. 🧘♀️
Итак, что вам нужно знать, чтобы разбираться в интеграциях в 2024:
🔲 JSON — язык разметки, чтобы читать и писать тела запросов и ответов в вызовах API
🔲 JSON Schema — чтобы описывать структуру JSON и валидировать документы
🔲 RegEx (ECMA-262) — чтобы задавать ограничения на формат для строковых полей
🔲 HTTP/1.1 — базовый протокол, нужно хотя бы понимать структуру запроса (метод, домен, путь, параметры, заголовок, тело, ошибки)
🔲 YAML — язык разметки для чтения и составления спецификаций OpenAPI
🔲 OpenAPI — собственно, стандарт для описания REST-подобных API.
🔲 XML, XSD — если вы работаете с государственными сервисами
🔲 WSDL — если у вас есть интеграции через SOAP
🔲 AsyncAPI — если у вас есть асинхронные интеграции, брокеры сообщений, очереди. Между прочим, уже версия 3.0.0 вышла, зрелый продукт!
🔲 AVRO — формат данных, часто использующийся в Kafka. Схема AVRO может быть включена в спецификацию AsyncAPI
🔲 OAuth 2.0 — протокол аутентификации авторизации
Про что нужно знать, что они есть, и рассматривать при необходимости:
🔲 Protobuf — формат данных gRPC, также может использоваться в Kafka, схему можно включить в AsyncAPI
🔲 JSON-RPC — легковесный формат вызова удаленных процедур через HTTP
🔲 GraphQL — формат описания схемы данных и язык запросов
🔲 TypeSpec — легковесный формат описания API, из которого генерируется спецификация OpenAPI (вот это я бы рекомендовал посмотреть — объем документа там в разы меньше, чем у OpenAPI)
🔲 XSLT — если вам приходится преобразовывать документы XML
🔲 JSLT или JSONata — как XSLT, но для JSON: языки запросов и преобразований
🔲 JSONPath — язык запросов к документу JSON
Для продвинутых и тех, кто занимается управлением API:
🔲 Модель OSI или TCP/IP — что происходит в сети на уровнях ниже HTTP
🔲 HAL — формат сообщений JSON, если вы хотите больше следовать принципам HATEOAS из REST
🔲 JSON:API — стандарт на формат сообщений (тоже в русле идей HATEOAS) и некоторые принципы формирования запросов
🔲 API Design Systems — язык спецификации правил для построения API (можно валидировать любое API в компании)
🔲 RFC 9457 — спецификация детального описания ошибок в ответах HTTP
🔲 JSON-Patch, JSON-Merge — форматы описания изменений документа JSON, то, что должно отправляться в команде PATCH
🔲 Overlay — спецификация изменений в документ OpenAPI
🔲 Arazzo — спецификация последовательности (воркфлоу) вызовов нескольких API
Вот, приятного чтения на каникулах 🙂 Специально поставил иконку пустого чек-бокса — можете мысленно отметить, что из этого вы уже знаете и с чем работали. 🧘♀️