Что такое REST и в чем заключается суть этого архитектурного стиля?

REST (Representational State Transfer) — это архитектурный стиль для проектирования сетевых API. Сформулировал его Рой Филдинг в 2000 году. Суть в том, что клиент и сервер общаются через единый интерфейс, используя стандартные HTTP методы и передавая состояние ресурсов.

Главное — разделение ответственности: сервер хранит и отдаёт данные (ресурсы), а клиент управляет их состоянием. Ресурс — это любая сущность (пользователь, заказ, статья), которая идентифицируется по URL. Например, GET /users/123 — запрос ресурса «пользователь с id 123».

• Единый интерфейс (Uniform Interface): четыре HTTP метода — GET (чтение), POST (создание), PUT/PATCH (обновление), DELETE (удаление). Никаких RPC-вызовов вроде /getUserData.action.
• Stateless (отсутствие состояния): каждый запрос от клиента содержит всю информацию, необходимую для его обработки. Сервер не хранит сессию. Это упрощает масштабирование — любой сервер может обработать любой запрос.
• Кеширование: ответы явно помечаются как кешируемые или нет (заголовки Cache-Control, Expires). GET-запросы кешировать безопасно, POST — нет.
• Слои (Layered System): между клиентом и сервером могут быть прокси, балансировщики, кеши. Клиент не обязан знать, сколько их.
• Code on Demand (опционально): сервер может передать код (например, JavaScript) для выполнения на клиенте. На практике редко используется.

Ключевая идея: работаем с представлениями ресурсов. Клиент не знает, как хранятся данные — он получает JSON/XML с полями. Пример: GET /books/42 → { "id": 42, "title": "Clean Code", "author": "Robert C. Martin" }. Клиент решает, что с этим делать.

Путают REST с RESTful API. RESTful — это API, следующий принципам REST. На практике большинство «RESTful» API нарушает одно из правил, чаще всего HATEOAS (гипермедиа как двигатель состояния приложения). HATEOAS — клиент должен переходить по ссылкам в ответе, а не знать URL заранее. Без него это скорее HTTP API.

Ошибки новичков: использовать POST для обновления, не возвращать коды статуса (200 OK для всего), делать URL вроде /updateUser вместо PUT /users/:id.