Что такое REST (RESTful API)?

Question

Что такое REST (RESTful API)?

Тип вопроса: Сети Вероятность: 28% Категория: PHP Разработчик

Ответ

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

Ключевые принципы REST:

Единообразие интерфейса (Uniform Interface):
- Ресурсы: Все сущности (пользователи, заказы) представляются как уникально идентифицируемые ресурсы (URI), например, /api/users/123.
- Манипуляции через представления: Клиент взаимодействует с ресурсом, отправляя представление (обычно JSON или XML) через стандартные HTTP-методы.
- Самодостаточные сообщения: Каждый запрос содержит всю информацию, необходимую для его обработки.
- HATEOAS (Hypermedia as the Engine of Application State): Ответы сервера содержат гиперссылки на возможные следующие действия.
Отсутствие состояния (Stateless): Сервер не хранит состояние клиента между запросами. Каждый запрос должен содержать всю необходимую аутентификационную и контекстную информацию (например, в заголовках).
Кэшируемость (Cacheable): Ответы должны явно указывать, можно ли их кэшировать и как долго, чтобы уменьшить нагрузку на сервер.
Клиент-серверная архитектура: Четкое разделение ответственности.
Многоуровневая система (Layered System): Архитектура может состоять из нескольких уровней (балансировщик, сервер приложений, БД), что повышает масштабируемость.

Пример RESTful-запроса и ответа:

GET /api/books/45 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer <token>

{
  "id": 45,
  "title": "Clean Code",
  "author": "Robert C. Martin",
  "_links": {
    "self": { "href": "/api/books/45" },
    "author": { "href": "/api/authors/12" }
  }
}

Стандартное соответствие HTTP-методов операциям (CRUD):

GET /api/books — получить список книг (Read).
POST /api/books — создать новую книгу (Create). Тело запроса содержит данные книги.
PUT /api/books/45 — полностью обновить книгу с id=45 (Update).
PATCH /api/books/45 — частично обновить книгу.
DELETE /api/books/45 — удалить книгу (Delete).

Использование кодов состояния HTTP:

200 OK — успешный запрос.
201 Created — ресурс создан.
400 Bad Request — ошибка в запросе клиента.
404 Not Found — ресурс не существует.
500 Internal Server Error — ошибка на сервере.

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

Ответ 18+ 🔞

Ну слушай, вот есть такая штука — REST. Это не какой-то там фреймворк или библиотека, это, блядь, архитектурный стиль, типа как подход к тому, как делать веб-сервисы, эти самые API. Если по-простому — свод правил, чтобы всё было единообразно и понятно, а не как попало, как у мартышлюшки в голове.

Основные принципы, на которых всё держится:

Единый интерфейс (Uniform Interface): Это главное, ёпта. Всё, с чем ты работаешь — пользователи, заказы, котики — это ресурсы. У каждого ресурса есть свой уникальный адрес (URL), типа /api/users/123. И ты делаешь с ними что хочешь, но только через стандартные HTTP-глаголы (GET, POST и т.д.), отправляя данные в JSON или XML. А ещё, хитрая жопа, ответы сервера должны содержать ссылки на то, что можно сделать дальше (это называется HATEOAS). Сам от себя охуеешь, когда поймёшь.
Без состояния (Stateless): Сервер — не твоя мамка, чтобы помнить, кто ты и что ты делал пять минут назад. Каждый твой запрос должен быть самодостаточным: тащи с собой все токены, логины и прочую хуйню в заголовках. Доверия ебать ноль между запросами.
Кэширование (Cacheable): Ответы сервера должны чётко говорить: «Меня можно кэшировать на столько-то секунд» или «Не трогай меня, я уникальный». Это чтобы не дрочить сервер одинаковыми запросами.
Клиент-сервер: Чёткое разделение. Клиент (приложение на телефоне, фронтенд) — одно, сервер (API) — другое. Каждый занимается своим делом и не лезет куда не надо.
Многоуровневая система (Layered System): Между тобой и базой данных может быть овердохуища прослоек: балансировщик, кэш-сервер, ещё чёрт в ступе. Тебе, как клиенту, да похуй. Ты общаешься с одним интерфейсом, а что там внутри творится — не твоя забота.

Вот смотри, как это выглядит на практике. Допустим, хочешь получить инфу о книге:

GET /api/books/45 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer <тут_твой_токен>

А сервер тебе в ответ:

{
  "id": 45,
  "title": "Clean Code",
  "author": "Robert C. Martin",
  "_links": {
    "self": { "href": "/api/books/45" },
    "author": { "href": "/api/authors/12" }
  }
}

Видишь эти _links? Это и есть та самая гиперссылочная магия HATEOAS. Типа «хочешь про автора — вот тебе ссылочка, иди туда».

Стандартная схема: какой HTTP-метод за что отвечает (это ж CRUD, блять):

GET /api/books — получить список всех книг (Read).
POST /api/books — создать новую книгу (Create). Данные о книге кидаешь в теле запроса.
PUT /api/books/45 — полностью перезаписать книгу с id=45 (Update).
PATCH /api/books/45 — точечно обновить только некоторые поля книги.
DELETE /api/books/45 — удалить книгу нахуй (Delete).

И, бля, коды ответов! Это важно, а то некоторые их игнорят, как пидарасы шерстяные.

200 OK — всё заебись, держи что просил.
201 Created — я твой ресурс создал, молодец.
400 Bad Request — ты мне какую-то хуйню прислал, исправляй запрос.
404 Not Found — нет тут такого ресурса, иди нахуй.
500 Internal Server Error — у меня, на сервере, пиздец случился, самому страшно.

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