Что такое REST и каковы его ключевые принципы?

Question

Что такое REST и каковы его ключевые принципы?

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

Ответ

REST (Representational State Transfer) – это архитектурный стиль для построения распределенных систем, основанный на стандартах и протоколах (в первую очередь, HTTP).

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

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

Пример корректного REST-запроса и ответа:

Запрос: GET /api/users/42 HTTP/1.1

Ответ (200 OK):

{
"id": 42,
"name": "Alice",
"email": "alice@example.com",
"_links": {
"self": { "href": "/api/users/42" },
"orders": { "href": "/api/users/42/orders" }
}
}

REST API обычно используют JSON или XML в качестве формата представления данных.

Ответ 18+ 🔞

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

REST (Representational State Transfer) – это, по сути, набор правил, как нормально, по-человечески, общаться клиенту с сервером через обычный HTTP. Не надо выдумывать свои протоколы, ебушки-воробушки, всё уже придумано до нас.

Основные правила, если хочешь, чтобы твоё API не было говном:

Единый интерфейс (Uniform Interface): Тут всё просто, как три копейки.
- Всё, с чем ты работаешь – книги, пользователи, котики – это ресурсы. У каждого ресурса есть свой уникальный адрес (URI). Хочешь книгу с id 123? Вот тебе /api/books/123. Не надо getBookById.php, блядь.
- Что делать с ресурсом, говорит HTTP-метод. Забыл? Напоминаю: GET – посмотреть, POST – создать, PUT – обновить целиком, PATCH – чутка подправить, DELETE – нахуй удалить. Всё! Больше ничего выдумывать не надо. Если твой «удалить» – это GET-запрос на /api/deleteUser?id=5, ты пидор конченый.
- Ответ должен быть самодостаточным. Серверу похуй, кто ты и что ты делал пять минут назад. Всё, что нужно для понимания ответа, лежит в самом ответе.
- HATEOAS – звучит страшно, а на деле: в ответе давай ссылки на связанные штуки. Получил пользователя – вот тебе ссылка на его заказы. Чтобы клиент не строил URL вручную, как последний бздун.
Без состояния (Stateless): Это святое. Каждый запрос – независимый. Сервер не должен помнить твою сессию, куки или что ты там авторизован. Всё, что нужно для аутентификации (например, токен), ты каждый раз суёшь в заголовки запроса. Если твой API ломается, потому что ты перезапустил сервер и он «забыл» клиентов – ты еблан.
Кэшируемость (Cacheable): Говори чётко: можно ли кэшировать ответ и на сколько. В HTTP для этого куча заголовков (Cache-Control, ETag). Это чтобы не дергать сервер по сто раз за одни и те же данные, как идиот.
Клиент-сервер: Ну тут всё ясно. Клиент (приложение на телефоне, фронт на React) – одна сторона. Сервер (твой бэкенд) – другая. Они общаются через API и не лезут в дела друг друга. Красота.
Слои (Layered System): Клиенту похуй, с кем он на самом деле говорит. С конечным сервером, балансировщиком нагрузки или прокси-кэшем. Это даёт овердохуища гибкости.

Пример, как это должно выглядеть, а не как у некоторых:

Запрос (клиент такой): GET /api/users/42 HTTP/1.1 Authorization: Bearer eyJhbGciOiJ... (вот, токен притащил, молодец)
Ответ (сервер, если всё ок):
```
{
"id": 42,
"name": "Alice",
"email": "alice@example.com",
"_links": {
"self": { "href": "/api/users/42" },
"orders": { "href": "/api/users/42/orders" }
}
}
```
Вот видишь? Данные в JSON (можно и в XML, но это уже как будто в пальто с чужого плеча). Есть ссылки (_links), по которым можно тыкать дальше. Чисто, аккуратно, понятно. Никакой ебли с сессиями, своими форматами и прочей хуйней. Вот это и есть RESTful API, а не то, что ты вчера на коленке написал.