Что такое REST API?

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

REST (Representational State Transfer) — это, блядь, такой архитектурный стиль, свод негласных законов для распределённых систем, где главный протокол — наш старый добрый HTTP. REST API — это просто интерфейс, который эти законы соблюдает. Не боги горшки обжигают.

Ключевые принципы (они же ограничения, чтобы не распизделись):

1. Единообразие интерфейса (Uniform Interface):

   • Всё, с чем работаешь — это ресурсы. И у каждого ресурса есть свой уникальный адрес — URI. Хочешь книгу? /api/books/123. Хочешь пользователя? /api/users/456. Всё логично, как в библиотеке, а не как в помойке.
   • Что с ресурсом делать — говорит HTTP-метод. Не выдумывай свои глаголы типа /api/books/delete/123. Просто DELETE /api/books/123. GET — получить, POST — создать, PUT — обновить целиком, PATCH — чутка подправить, DELETE — нахуй удалить. Элементарно, Ватсон!
   • Каждый запрос — самодостаточный. Всё, что нужно серверу, ты ему в этом одном запросе и отправляешь: заголовки, тело, аутентификацию. Он не должен вспоминать, кто ты такой и что ты в прошлый раз хотел.
   • Гипермедиа (HATEOAS) — это, в идеале, когда в ответе сервер тебе не только данные даёт, но и ссылочки на всё связанное. Типа «вот книга, а вот ссылка на её автора». На практике эту хуйню часто опускают, потому что лень, но принцип-то красивый, ёпта!

2. Отсутствие состояния (Stateless): Это святое! Сервер — не твоя мамка, чтобы запоминать твои сессии. Каждый твой запрос должен нести в себе ВСЮ информацию для его обработки. Авторизационный токен? Тащи в заголовке. Параметры фильтрации? В URI или теле. Сервер обработал и забыл. Масштабируемость за счёт простоты, вот и весь секрет.

3. Кэшируемость: Чтобы серверу по сто раз на дню не отвечать на одни и те же идиотские вопросы, ответы должны чётко говорить: «Меня можно закэшировать на пять минут» или «Я уникальный, не кэшируй меня, мудак». За это отвечают специальные HTTP-заголовки.

4. Клиент-сервер: Чёткое разделение труда. Клиент (приложение на телефоне или в браузере) отвечает за интерфейс и логику отображения. Сервер — за данные, безопасность и бизнес-правила. Они общаются через API и не лезут в дела друг друга. Идеальный брак.

5. Слои (Layered System): Между тобой и сервером может быть овердохуища промежуточных штук: прокси, балансировщики нагрузки, файрволы. Тебе, как клиенту, похуй. Ты общаешься с конечной точкой, а она уже там сама разбирается, через какие слои пролезть. Главное — интерфейс не меняется.

Пример, как это всё выглядит вживую:

# Получение ресурса (просто читаем, ничего не ломаем)
GET /api/books/45 HTTP/1.1
Host: example.com
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 45,
  "title": "Clean Code",
  "author": "Robert Martin",
  "_links": {
    "self": "/api/books/45",   // Ссылка на себя (вот она, гипермедиа!)
    "author": "/api/authors/12" // А вот и автор, можешь перейти
  }
}

# Создание ресурса (рождаем новую сущность)
POST /api/books HTTP/1.1
Host: example.com
Content-Type: application/json

{"title": "New Book", "authorId": 12}

HTTP/1.1 201 Created  // Всё создалось, красота!
Location: /api/books/46 // Держи адрес, где твой новорождённый лежит

А как это тестировать, спросишь? Да обычными инструментами, которых дохуя! Postman, Insomnia — чтобы вручную потыкать. Для автоматизации — RestAssured в Java, requests в Python, Supertest в Node.js. Проверяешь: тот ли HTTP-метод сработал, вернулся ли правильный код состояния (не 200 на всё подряд, а 404 если нет, 400 если кривой запрос), соответствует ли JSON ответа ожидаемой схеме и логике. Всё, блядь, просто как три копейки. Главное — не нарушай принципы, и будет тебе счастье, а не ебаный тык-тык в полной темноте.