Сколько обязательных методов в REST API и назови два из них

Что проверяют

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

Как отвечать

Прямой ответ: обязательных методов у REST нет. REST задаёт ограничения стиля, единый интерфейс среди них, но списка глаголов не диктует. Глаголы задаёт HTTP, и там обязательными для сервера общего назначения считаются GET и HEAD.

Дальше дайте то, чего от вас ждут: рабочий набор CRUD это GET, POST, PUT, DELETE, к ним PATCH для частичного обновления и OPTIONS для предварительных запросов. Назовите два и сразу раскройте семантику:

• GET читает и ничего не меняет, ответ кэшируется, тела у запроса нет;
• POST создаёт подчинённый ресурс, не идемпотентен, в ответ идёт 201 Created и заголовок Location.

Полезно добавить сетку свойств: безопасные это GET, HEAD, OPTIONS; идемпотентные это они же плюс PUT и DELETE; POST и PATCH идемпотентность не гарантируют.

В ASP.NET Core это ложится на атрибуты [HttpGet], [HttpPost], [HttpPut], [HttpDelete] у контроллера или на MapGet и MapPost в минимальном API.

Где спотыкаются

Путают PUT и PATCH. PUT заменяет представление ресурса целиком и потому идемпотентен, PATCH присылает описание изменений. Отправить в PUT половину полей и ждать частичного обновления значит незаметно обнулить остальные.

Смешивают безопасность и идемпотентность. Говорят, что DELETE не идемпотентен, раз второй вызов вернёт 404. Идемпотентность про состояние сервера, а оно после второго вызова то же самое.

Называют все четыре глагола и тут же описывают API, где всё ходит через POST на /api/getUser и /api/updateUser, а ошибки возвращаются кодом 200 с полем error в теле. Это RPC поверх HTTP, и на уточняющем вопросе про коды ответов разговор обычно и заканчивается.