Как ответить
REST (Representational State Transfer) — это архитектурный стиль взаимодействия компонентов распределённой системы по протоколу HTTP. В основе лежит работа с ресурсами, где каждый ресурс идентифицируется уникальным URL, а клиент и сервер обмениваются представлениями этих ресурсов (обычно в формате JSON или XML).
Главная идея в том, что сервер не хранит состояние клиента (Stateless). Каждый запрос должен содержать всю информацию, необходимую для его обработки. Это позволяет легко масштабировать систему, так как любой инстанс сервера может обработать запрос от любого клиента.
Для управления ресурсами используются стандартные методы HTTP:
- GET — запрашивает данные. Это безопасный и идемпотентный метод: он не должен менять состояние сервера, а повторные вызовы возвращают один и тот же результат.
- POST — создает новый ресурс. Метод не является идемпотентным: два одинаковых запроса создадут две записи в базе данных. Часто используется для отправки форм или загрузки файлов.
- PUT — полностью заменяет ресурс по указанному адресу. Если ресурса нет, он может быть создан. Метод идемпотентен: сколько бы раз мы ни отправляли одни и те же данные, итоговое состояние ресурса на сервере будет одинаковым.
- PATCH — частично обновляет ресурс. В отличие от PUT, здесь передаются только те поля, которые нужно изменить.
- DELETE — удаляет ресурс. Метод идемпотентен: повторный вызов вернёт либо подтверждение удаления, либо 404, но состояние системы не изменится.
Пример структуры запроса для получения списка пользователей и создания нового:
// Получить список активных пользователей
GET /api/v1/users?status=active
// Создать нового пользователя
POST /api/v1/users
Content-Type: application/json
{
"name": "Ivan",
"email": "ivan@example.com"
}Важная часть REST — правильное использование кодов ответа (Status Codes). Для успешных операций это группа 2xx (200 OK, 201 Created), для ошибок клиента — 4xx (400 Bad Request, 401 Unauthorized, 404 Not Found), для ошибок сервера — 5xx (500 Internal Server Error).
Также по стандарту RESTful API должен стремиться к уровню HATEOAS, когда сервер в ответе передаёт ссылки на связанные действия, но на практике в коммерческой разработке это встречается редко.