Приведите пример REST-запроса
Что проверяют
Умеете ли вы описать вызов API так, чтобы по описанию его реализовали без уточнений. Аналитику мало произнести «GET и POST»: важно, что вы называете все части запроса, различаете параметры пути и строки запроса и понимаете, какой код ответа обещаете клиенту.
Как отвечать
Покажите запрос целиком, а потом разберите по частям:
GET /api/orders?status=new&limit=20 HTTP/1.1
Host: shop.example.com
Accept: application/json
Authorization: Bearer <token>Части такие: метод говорит, что делаем; путь называет ресурс существительным во множественном числе, идентификатор конкретной записи идёт в пути; строка запроса несёт фильтр, сортировку и страницу; заголовки задают формат ответа и авторизацию; тело появляется у методов, которые что-то меняют.
Дальше пройдитесь по методам и кодам. GET читает, POST создаёт, PUT заменяет представление целиком, PATCH меняет часть полей, DELETE удаляет. Ответы: 200 на чтение, 201 вместе с заголовком Location на создание, 204 без тела на удаление, 400 на неразобранный запрос, 401 и 403 на неизвестного и на запрещённого, 404 на отсутствующий ресурс, 409 на конфликт, 422 на непрошедшую проверку правил.
Закончите тем, что для аналитика описание не сводится к счастливому пути: нужны обязательность и формат каждого поля, пример ошибки и поведение при повторе запроса.
Где спотыкаются
Кладут глагол в путь: /getOrders, /createOrder. Действие уже выражено методом, адрес называет ресурс. Такой ответ сразу показывает, что REST для кандидата это просто «запросы по HTTP».
Второе: путают PUT и PATCH. Замена целиком означает, что непереданные поля обнулятся, частичное изменение это PATCH. Ошибка дорогая: по такому описанию разработчик сотрёт данные, которых в теле не оказалось.
Третье: отвечают кодом 200 на всё подряд и прячут ошибку в теле. Клиенту приходится разбирать текст, чтобы понять, что случилось, а стандартная обработка на стороне библиотек и промежуточных узлов перестаёт работать.