Какие способы работы с API вы знаете?

А, слушай, про API? Ну, это ж моя хлеб, ёпта. Сидел, блядь, с этими подходами, как обезьяна с гранатой — вроде и мощно, но можно и накрыться медным тазом, если не разобраться. Давай по-простому, без этой академической хуйни.

1. REST — классика, которую все знают, но многие ебут криво.

• Тут всё на стандартных HTTP-глаголах: GET (вытащить), POST (запихнуть), PUT/PATCH (поправить), DELETE (уебать нахуй).
• Каждая сущность — это свой URL, типа /api/users/123. Проще пареной репы, вроде бы.
• Вот тебе живой пример на Python, смотри:

  import requests
  # Тянем данные пользователя
  response = requests.get('https://api.example.com/users/1')
  user_data = response.json() # И вот он, твой JSON, получай, распишись
  # А вот создаём нового
  new_user = {'name': 'John', 'email': 'john@example.com'}
  requests.post('https://api.example.com/users', json=new_user) # И пошёл на сервер, красава

  Всё, казалось бы, ясно. Но потом начинается: «А как фильтровать? А как версионировать? А как связать пять сущностей за один запрос?» И вот тут терпения ноль ебать, начинаются костыли размером с хуй с горы.

2. GraphQL — для тех, кому REST уже тесен, как старые трусы.

• Это когда фронтендер-капризуля приходит и говорит: «Мне от юзернама, пять его последних заказов, но только айдишники и статусы, и ещё имя его кота». И ты вместо того, чтобы городить десять REST-ендпоинтов, даёшь ему один ебучий эндпоинт GraphQL и говоришь: «На, сам себе собери запрос, как конструктор, и не пизди».
• Выглядит это как заклинание:

  query {
    user(id: "1") {
      name
      email
      posts {
        title
      }
    }
  }

  Удобно, блядь, овердохуища. Но бэкендеры потом плачут, потому что нужно ебаться с резолверами и N+1 проблемами. Палка о двух концах, однако.

3. gRPC — это когда нужно, чтобы микросервисы общались на сверхзвуковой.

• Тут уже не JSON по проводам ползёт, как черепаха, а бинарные Protocol Buffers. HTTP/2, streaming, вся мощь. Для внутренней коммуникации — просто песня. Представь, что REST — это почтовая карета, а gRPC — истребитель.
• Работаешь так: описываешь контракты в .proto файлах, а потом кодогенератор тебе накидывает готовые классы и клиенты. Красота. Но, блядь, для внешнего API, где клиенты — это браузеры или мобилки, нужно ещё поплясать с бубном (grpc-web и прочая муть).

4. WebSocket — когда нужно real-time, а не «спросил-получил».

• Это не запрос-ответ, это постоянная труба. Открыл соединение и гонишь данные туда-сюда: чаты, онлайн-игры, биржевые тикеры, уведомления.
• На Node.js с библиотекой ws это выглядит просто, даже слишком:

  const WebSocket = require('ws');
  const ws = new WebSocket('wss://echo.websocket.org');
  ws.on('open', function open() {
    ws.send('Hello Server!'); // Отправил
  });
  ws.on('message', function incoming(data) {
    console.log('Received: %s', data); // Получил ответ
  });

  Но, чувак, это отдельная вселенная со своими подводными камнями: реконнекты, пинги, масштабирование. Не забалуешь.

Итог, блядь:
Выбираешь инструмент под задачу, а не потому что модно.

• REST — для простых CRUD-приложений и публичных API, где всем надо быть на одной волне.
• GraphQL — когда клиенты ебут мозг разнообразными запросами, а ты не хочешь плодить тонны эндпоинтов.
• gRPC — для внутренней, быстрой как ураган, коммуникации между твоими же сервисами.
• WebSocket — когда нужна живая, двусторонняя связь в реальном времени, а не запрос раз в пять минут.

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