Какие знаешь виды запросов REST

Разбор вопроса «Какие знаешь виды запросов REST» для Frontend Developer: что проверяет интервьюер, ключевые тезисы, практические примеры и частые ошибки.

Интервьюер хочет убедиться, что кандидат понимает основные HTTP-методы, используемые в REST API, их назначение и свойства (идемпотентность, безопасность). Важно кратко объяснить каждый метод и привести примеры использования.

Ключевые тезисы

GET — запрос для получения данных с сервера. Безопасный и идемпотентный, не изменяет состояние сервера.
POST — запрос для отправки данных на сервер (например, создание новой сущности). Не идемпотентный и не безопасный.
PUT — запрос для полного обновления существующей сущности на сервере. Идемпотентный, но не безопасный.
PATCH — запрос для частичного обновления сущности. Не идемпотентный и не безопасный.
DELETE — запрос для удаления сущности на сервере. Идемпотентный, но не безопасный.
HEAD — аналогичен GET, но возвращает только заголовки без тела ответа. Используется для проверки доступности ресурса.
OPTIONS — запрос для получения информации о поддерживаемых методах для ресурса.

Подробный ответ

REST API использует стандартные HTTP-методы для выполнения операций с ресурсами. Основные виды запросов включают GET, POST, PUT, PATCH, DELETE, HEAD и OPTIONS. GET используется для получения данных с сервера и является безопасным (не изменяет состояние сервера) и идемпотентным (повторные запросы дают одинаковый результат). POST применяется для создания новых ресурсов, не является ни безопасным, ни идемпотентным. PUT полностью обновляет существующий ресурс, он идемпотентен, но не безопасен. PATCH выполняет частичное обновление ресурса и не обладает ни одним из этих свойств. DELETE удаляет ресурс и является идемпотентным. HEAD и OPTIONS служат для получения метаинформации о ресурсе и поддерживаемых методах соответственно.

Практические примеры

Пример 1

Пример GET запроса: получение списка пользователей через fetch('https://api.example.com/users'). Сервер вернет массив пользователей в формате JSON.

Пример 2

Пример POST запроса: создание нового пользователя через `fetch('https://api.example.com/users', { method: 'POST', body: JSON.stringify({ name: 'John' }) })`. Сервер создаст нового пользователя и вернет его ID.

Пример 3

Пример PUT запроса: обновление данных пользователя через `fetch('https://api.example.com/users/1', { method: 'PUT', body: JSON.stringify({ name: 'John Doe' }) })`. Сервер полностью заменит данные пользователя с ID 1.

Частые ошибки

Использование GET для передачи чувствительных данных (например, паролей) в URL, что небезопасно из-за логгирования URL.
Путаница между PUT и PATCH: PUT заменяет весь ресурс, а PATCH только его часть.

Связанные темы

HTTP статусы ответов (200, 201, 404 и др.)
Идемпотентность и безопасность методов
RESTful архитектура
Аутентификация в API (OAuth, JWT)

Follow-up вопросы

В чем разница между PUT и PATCH?

Уровень: basic

PUT полностью заменяет ресурс на сервере данными из запроса, тогда как PATCH вносит частичные изменения. PUT идемпотентен (повторные запросы дают тот же результат), а PATCH — нет.

Почему GET считается безопасным методом?

Уровень: basic

GET не изменяет состояние сервера и предназначен только для получения данных. Он не должен иметь побочных эффектов, что делает его безопасным для многократного вызова.

Какой HTTP-метод следует использовать для создания вложенного ресурса?

Уровень: intermediate

Для создания вложенного ресурса обычно используют POST, так как он не требует идемпотентности. URL при этом будет указывать на родительский ресурс (например, /posts/{id}/comments).

Можно ли использовать GET для передачи чувствительных данных? Почему?

Уровень: intermediate

Нет, GET не подходит для чувствительных данных, так как параметры передаются в URL и могут сохраняться в истории браузера, логах сервера и других местах. Для этого лучше использовать POST с HTTPS.

Как реализовать идемпотентность для неидемпотентных методов (например, POST)?

Уровень: advanced

Для этого можно использовать уникальные идентификаторы запросов (idempotency keys), которые сервер запоминает и игнорирует повторные запросы с тем же ключом. Это часто применяется в платежных системах.