Код состояния ответа HTTP для плохих данных, найденных в DB

Я ожидаю, что ответ JSON, возвращенный одним из моих веб-API, будет содержать минимальный набор полей, аннотированных как обязательные для бизнеса.Код состояния ответа HTTP для плохих данных, найденных в DB

Какой HTTP status code подходит лучше в случае, если некоторые плохие данные, которые не соответствуют контракту, находятся на db?

В настоящее время мы используем 500, но нам, вероятно, необходимо его улучшить (также потому, что Varnish, поставленный перед нашим сервисом, переводит 500 в 503 Service Unavailable).

Пример:

{ 
    "id": "123", 
    "message": "500 - Exception during request processing. Cause: subtitles is a required field of class Movie and cannot be empty", 
    "_links": { 
    "self": { 
     "href": "/products/movies/123" 
    } 
    } 
}

Благодаря

источник

2016-08-19 Ga Sacchi

Я бы подумал, что если это плохие данные, это должно быть 400 плохого запроса? – mituw16

Качните эти ссылки, они могут быть полезны: http://stackoverflow.com/questions/1434315/http-status-code-for-database-is-down и http://stackoverflow.com/questions/3290182/rest-http -status-codes-for-failed-validation-or-invalid-duplicate – d3r1ck

Нет запроса, это просто ответ, который является «плохим», потому что такие же неожиданные данные были найдены на db –

500 Внутренняя ошибка сервера, кажется, здесь достаточно, чтобы быть честным, поскольку этот вопрос, по существу, на стороне сервера, и он не отражает какой-либо неправильно делать из клиентская сторона.

источник

2016-08-19 13:50:19

400 означает BAD-запрос, но нет ничего плохого в запросе, поэтому не используйте его.

500 означает, что ошибка сервера, как в чем-то неожиданном, - код взорвался, галактика разбилась. Плохие данные не являются причиной этого.

У вас есть случай с плохими данными, поэтому у вас есть ряд подходов в вашем распоряжении.

Первый вопрос: что вы намерены делать с плохими данными?

Вы можете удалить его, и в этом случае вы вернете 204, что означает, что запрос в порядке, но нет данных для отправки назад. Я бы не возвращал 404 без данных, потому что 404 означает, что конечная точка не существует, а данные не существуют.
Вы можете переместить его из главного db в временные данные, когда кто-то его исправит.

В любом случае вы не будете возвращать плохие данные, а клиенту все равно, почему эти данные плохие. Весь клиент заинтересован в наличии каких-либо данных или нет. Почему клиент должен заботиться о том, чтобы у ваших данных не было поля, которое вы считаете важным?

Вы можете использовать другой подход и вернуть данные, которые у вас есть.

Подводя итог: решайте, как вы имеете дело с плохими данными и не ставите на клиента никакой ответственности.

источник

2016-08-19 16:57:23

Код состояния ответа HTTP для плохих данных, найденных в DB

ответ

Смежные вопросы