Что такое REST API и его основные принципы?

Э, слушай, смотри, вот эта вся ваша REST API хуйня, она на самом деле проще, чем кажется, если не забивать голову умными книжками. Представь себе барную стойку, только для программ.

REST API — это, блядь, такой способ твоему приложению-клиенту общаться с сервером, как будто он заказывает напитки у бармена. Использует он для этого обычный HTTP, который везде, а данные шлёт в JSON — это как меню, которое все понимают.

Вот на чём вся эта архитектура держится, её основные правила, блядь:

1. Единый интерфейс, как у всех нормальных баров (Uniform Interface)

   • Всё — ресурс. Хочешь пользователей? Вот тебе /api/users. Хочешь конкретного? На, /api/users/1. Это как сказать: «Дайте мне водки» или «Дайте мне вот ту самую бутылку «Белуги» с верхней полки».
   • Работаешь с копией. Ты ж не лезешь за стойку сам наливать? Ты говоришь бармену. Он тебе приносит стакан (JSON) — вот это и есть представление ресурса. Работаешь с ним.
   • В каждом заказе всё есть. «Мне виски со льдом, вот мои права и деньги». Серверу не надо помнить, что ты там пять минут назад спрашивал. Всё в одном запросе.
   • HATEOAS (этот ёбаный акроним). Это когда в ответе тебе ещё и намекают, что делать дальше. Типа: «Вот твой заказ, а к нему можно взять чипсы (ссылка /api/snacks) или рассол (ссылка /api/pickles)».

2. Без состояния (Stateless) — главное правило!

   • Сервер — золfish, ёпта. Он тебя не помнит от слова совсем. Пришёл новый запрос — для него ты новый клиент. Поэтому в каждом своём «заказе» ты должен таскать с собой все свои «документы» (токен в заголовках, обычно). Иначе получишь 401 Unauthorized и пойдёшь нахуй.

3. Кэшируемость (Cacheable)

   • Чтобы серверу по сто раз не делать одно и то же, он может сказать: «Информация по акциям на пиво обновляется раз в час, так что запомни (закэшируй) этот ответ и не дергай меня попусту».

4. Клиент-сервер

   • Ну тут всё ясно. Клиент (приложение на телефоне) — это ты, который орет «Мне пива!». Сервер — это бармен, который знает, где пиво хранится, сколько стоит и имеет право тебе его налить (или нет).

5. Многоуровневость (Layered System)

   • Между тобой и барменом может быть цепочка: ты -> вышибала (балансировщик) -> официант (шлюз) -> сам бармен. Ты этого не видишь и тебе похуй. Это для масштабируемости и безопасности.

А вот самое сочное — как HTTP-методы с CRUD соотносятся. Запоминай, это основа:

Ну и пример, как это выглядит вживую, блядь:

### Клиент создаёт новый заказ (POST)
POST /api/orders HTTP/1.1
Host: bar.example.com
Content-Type: application/json
Authorization: Bearer <мой_токен_чтоб_меня_узнали>

{
  "drink": "Виски",
  "quantity": 2
}

// Ответ бармена-сервера (201 Created — создано, молодец)
HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/9001 // Смотри, заказ под номером 9001!

{
  "id": 9001,
  "drink": "Виски",
  "quantity": 2,
  "status": "В процессе наливания",
  "createdAt": "2023-10-01T12:00:00Z",
  "_links": { // Ссылочки, тот самый HATEOAS, на!
    "self": { "href": "/api/orders/9001" },
    "add_snack": { "href": "/api/orders/9001/snacks" } // Можешь ещё закуску добавить
  }
}

И напоследок, коды ответов, их проверяй всегда, а то останешься без пива:

• 2xx — Всё охуенно, проходи (200 OK, 201 Created).
• 4xx — Это ты, мудак, накосячил (400 — хуёвый запрос, 401 — не представился, 403 — доступ запрещён, 404 — такого ресурса нет, иди нахуй).
• 5xx — Это уже сервер обосрался (500 — внутренняя ошибка, 502 — плохой шлюз, и т.д.).

Вот и вся магия, ёпта. Никакой чертовщины, просто договорённости, как общаться. Просто, как три копейки, и поэтому везде используется.