Чем отличаются подходы к созданию API: REST, SOAP и GraphQL

Слушай, давай я тебе на пальцах объясню, про эти три штуки, которые все называют API, а на деле — три разных планеты, блядь. Прям как в сказке: один — деревянный, другой — луковка, третий — вообще непонятно кто, в рот меня чих-пых!

REST — это наш старый добрый работяга, который всё по полочкам.

Представь себе библиотеку, сука. У тебя есть полка с книгами (/books), полка с авторами (/authors). Хочешь книгу — иди на полку книг и делай GET /books/123. Хочешь добавить новую — POST /books. Всё просто, как три копейки, блядь. Он ресурсо-ориентированный, то есть всё крутится вокруг этих самых «полок»-ресурсов.

• Чем хорош? Простой, понятный, его везде поддержат. Stateless, то есть он тебя не помнит — пришёл, взял, ушёл. Кэшируется на ура.
• Чем бесит? А тем, что он тупой, как пробка! Запросил книгу — получи ВСЮ книгу: и обложку, и оглавление, и все 500 страниц текста, даже если тебе только название нужно было. Это over-fetching, ёпта! Или наоборот: получил книгу, а там нет имени автора, приходится лезть на другую полку (/authors/456). Это under-fetching, блядь! Вечно бегаешь туда-сюда.

SOAP — это такой матёрый, консервативный бухгалтер в костюме тройке.

Он не «стиль», он ПРОТОКОЛ, сука! Всё по правилам, всё по бумажкам. Он как будто из 2000-х, когда XML был царём и богом. Он не «полками» думает, а «процедурами»: «Вызови-ка мне, дружок, процедуру GetUserDetails».

• Чем хорош? Надёжный, как швейцарский банк. В нём из коробки встроена куча всякой ебанины: безопасность, транзакции, гарантии доставки. Его обожают большие банки и корпорации, где бумажка важнее жизни.
• Чем бесит? Да всем, блядь! Он жутко сложный и жирный. Каждое сообщение — это такая портянка из XML, где полезных данных — 10%, а остальное — служебные теги, ебать его в сраку. Медленный, неповоротливый. WSDL-контракт у него — это отдельная песня, документ на сто страниц, который надо сначала изучить, чтобы просто «поздороваться».

GraphQL — это хипстер-программист, который говорит: «Зачем бегать? Скажи мне ЧТО хочешь, и я ВСЁ принесу ОДНИМ разом».

Это вообще не протокол, а язык запросов, ёбта! У тебя не куча полок, а один умный официант. Ты ему на салфетке пишешь заказ: «Принеси-ка пиццу, но только без грибов, зато с двойным сыром. И колу, но диетическую. И всё это на одном подносе».

• Чем хорош? Мощь, блядь! Клиент сам решает, что ему нужно. Нет проблем с over/under-fetching. Хочешь только имя пользователя и аватарку — пожалуйста. Хочешь его имя, последние 5 заказов и кота — тоже ок. Один эндпоинт на все случаи жизни. Схема типов — красота, всё строго.
• Чем бесит? Сложность перекладывается на сервер, сука. Сделать хорошо работающий GraphQL-сервер — это надо постараться. Кэшировать сложнее. И если накосячить с запросами, можно так нагрузить базу, что она взвоет, как сука.

Вот, смотри, как это выглядит в коде. GraphQL-запрос — это просто бланк:

# Запрос клиента: "Дай пользователя 101, но только его айди и имя. На почту и прочую хуйню мне похуй"
query GetUser {
  user(id: "101") {
    id
    name
  }
}

# Ответ сервера: "На, довольствуйся, засранец. Ровно то, что просил."
{
  "data": {
    "user": {
      "id": "101",
      "name": "John Doe"
    }
  }
}

А теперь, чтобы ты совсем не запутался, вот тебе табличка, ёперный театр:

Короче, выбор зависит от задачи. Простенький мобильный бекенд? REST — и не еби мозг. Банковские переводы между конторами? SOAP, ибо надёжность. Сложное фронтенд-приложение с кучей данных? GraphQL, чтобы не сойти с ума от кучи запросов.

Вот и вся философия, блядь. Выбирай с умом, а то потом будешь, как Герасим, молча страдать.