HTTP REST Response в случае сбоя зависимой операции

Question

Предположим, что вызывающий абонент отправляет POST-запрос на REST-сервер для создания ресурса. Сервер создает ресурс и возвращает 201.

Теперь код сервера модифицируется для выполнения других операций, если ресурс создан успешно. Этими операциями может быть что угодно - создание другого ресурса для бухгалтерии, обновление другого ресурса и т. Д. c.

Если любая из этих зависимых операций завершится неудачно, должен ли сервер вернуть 201 вызывающей стороне (как предполагаемый ресурс) был создан) ИЛИ привести к сбою (даже если вызывающий абонент не знает об этих зависимых ресурсах / не обеспокоен ими)?

Answer 1

Как пишется большая часть HTTP spe c, запросы обычно либо полностью выполняются, либо полностью завершаются неудачей.

Однако к этому можно применить некоторые нюансы.

Если состояние сервера изменено, и предполагается, что такой HTTP-запрос может выполнить одно или несколько действий, я бы сказал, что вы можете считать это «успешным», и вам следует вернуть ответ 2XX.

Если я получу ответ 4XX, запрос должен иметь полностью сбой , хотя.

Answer 2

Когда вы возвращаете HTTP-статус 201, вы должны возвращать ресурс, созданный в ответе, если операция не удалась, вы не должны возвращать 201 в первую очередь.

В любом случае, коды состояния HTTP в основном используются проверить статус самого запроса, а не логики, стоящие за ним. Лучший способ - всегда возвращать 200, когда сам запрос выполнен успешно. В теле ответа вы можете вернуть некоторую дополнительную информацию об операциях, например, логическое значение, были ли действия успешными или нет в формате JSON.

Answer 3

HTTP-ответы относятся к запросу, в случае успеха возврат всегда будет успешным. Например, список таблицы в базе данных, которая должна содержать данные, но пустая, вернется успешно, поскольку целью по умолчанию было просто перечислить таблицу.

Определение всех кодов ответов можно найти здесь: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

Что можно использовать, так это использовать язык программирования для обработки возврата вашего API, создавая условные выражения для возврата настраиваемого HTTP-ответа на основе того, что вы понимаете как запрос на успешное выполнение или нет.