Какие архитектуры API вы знаете?

Question

Какие архитектуры API вы знаете?

Тип вопроса: API тестирование Вероятность: 10% Категория: QA Тестировщик

Ответ

Основные архитектуры API включают:

REST (Representational State Transfer)
- Принцип: Использует стандартные HTTP-методы (GET, POST, PUT, DELETE, PATCH) для операций с ресурсами, идентифицируемыми через URL.
- Формат данных: JSON или XML.
- Пример запроса:
```
GET /api/users/1 HTTP/1.1
Host: example.com
Accept: application/json
```
- Плюсы: Простота, кэшируемость, несостоятельность (stateless).
GraphQL
- Принцип: Позволяет клиенту формировать запросы для получения только необходимых данных, избегая проблемы недополучения или избыточности данных (over-fetching/under-fetching).
- Пример запроса:
```
query {
  user(id: 1) {
    name
    email
    posts(limit: 5) {
      title
    }
  }
}
```
- Плюсы: Гибкость, единая конечная точка (endpoint), строгая типизация схемы.
SOAP (Simple Object Access Protocol)
- Принцип: Строгий протокол на основе XML. Использует WSDL (Web Services Description Language) для описания сервиса.
- Плюсы: Высокая стандартизация, встроенная безопасность (WS-Security), надежность (встроенные механизмы повторных попыток).
- Минусы: Сложность и избыточность (большой объем передаваемых данных).
RPC (Remote Procedure Call)
- Принцип: Клиент вызывает удаленную процедуру (функцию) на сервере, как локальную.
- Реализации:
  - gRPC: Высокопроизводительный фреймворк от Google, использует бинарный протокол Protocol Buffers (protobuf).
  - JSON-RPC: Легковесный протокол, использующий JSON для кодирования вызовов.

Ответ 18+ 🔞

Давай разберём эти ваши API-архитектуры, а то народ путается, как будто в тёмной комнате хуи ищет.

Ну вот смотри, первое — это REST. Представь, что у тебя есть сайт с котиками. Каждый котик — это ресурс, у него свой уникальный адрес, типа /api/cats/42. Хочешь посмотреть на кота — шлёшь GET. Хочешь добавить нового мурлыку — POST. Старый кот обосрался в тапок, нужно обновить запись — PUT или PATCH. Кот сбежал к соседям — DELETE, и хуй с ним. Всё просто, как три копейки. Данные туда-сюда в JSON летают. Плюсы? Да похуй, статичен, кэшируется, и серверу на тебя насрать — он состояние не помнит.

GET /api/cats/42 HTTP/1.1
Host: example.com
Accept: application/json

Дальше идёт GraphQL. Это, блядь, для тех, кому REST — как сесть на хуй: неудобно и данных либо мало, либо овердохуища. Тут клиент — царь и бог: сам говорит, что ему нужно, а что нет. Не хочешь получать про кота его дату рождения и список бывших хозяев — не получаешь. Один ебучкий эндпоинт на все случаи жизни, и схема строгая, чтоб не выёбывался.

query {
  cat(id: 42) {
    name
    breed
    toys(limit: 3) {
      name
    }
  }
}

А теперь, ёпта, SOAP. Это такой дедушка в костюме тройке, который всё делает по протоколу, с бумажками. XML, блядь, тоннами, куча стандартов, безопасность, надёжность — всё есть. Но сложность, сука, такая, что проще самому написать свой протокол на коленке. Данных передаёт — мама не горюй, будто не сообщение, а целую библию отправил. Для банков, госов и прочих любителей пострадать.

И наконец, RPC. Вообще, идея простая — вызвать функцию на другом конце провода, как будто она тут, рядом. gRPC — это от Гугла, быстрый, бинарный, для своих. JSON-RPC — попроще, на JSON'е. Всё бы ничего, но когда этих удалённых процедур становится, как говна за баней, начинается пиздец — следить за ними сложно, версионировать — вообще жесть. Но для микросервисов, где свои на своих бьют, — самое то.

Короче, выбирай по потребностям: хочешь просто и понятно — REST, хочешь гибко — GraphQL, нужно для старого говна с гарантиями — SOAP, а если скорость и контроль — gRPC. Главное — не выдумывай велосипед, их уже дохуя изобрели.