Ошибка API REST возвращает хорошие практики [закрыто]
Работа над такой же функциональностью приводит меня к такому подходу: (nodejs, es6, Promise)
var deleteRecords = function (tblName, data) {
return new Promise((resolve, reject) => {
var jdata = JSON.stringify(data);
this.run(`DELETE FROM ${tblName} WHERE id IN (?)`, jdata.substr(1, jdata.length - 2), function (err) {
err ? reject('deleteRecords failed with : ' + err) : resolve();
});
});
};
7 ответов
Итак, сначала у меня возникло искушение вернуть ошибку моего приложения с 200 OK и конкретными полезными данными XML (т. Е. Заплатите нам больше, а вы » Я получу необходимое хранилище!) но я перестал думать об этом, и это кажется мыльным (/ в ужасе пожимает плечами).
Я бы не стал ' t вернуть 200, если действительно с запросом не было ничего плохого. Из RFC2616 , 200 означает «запрос выполнен успешно».
Если квота хранилища клиента была превышена (по какой-либо причине), я бы вернул 403 (Запрещено):
Сервер запрос понял, но отказывается его выполнить. Авторизация не поможет, и запрос НЕ ДОЛЖЕН повторяться. Если метод запроса не был HEAD и сервер желает обнародовать, почему запрос не был выполнен, он ДОЛЖЕН описать причину отказа в объекте. Если сервер не желает предоставлять эту информацию клиенту, вместо него можно использовать код состояния 404 (Not Found).
Это сообщает клиенту, что запрос был в порядке, но не удался (что-то 200 не соответствует не делаю).
Как указывали другие, наличие объекта ответа в коде ошибки вполне допустимо.
Помните, что ошибки 5xx являются серверными, иначе клиент не может ничего изменить в своем запросе на сделать запрос пройденным. Если квота клиента превышена, это определенно не ошибка сервера, поэтому следует избегать 5xx.
Главный выбор - рассматривать ли код состояния HTTP как часть вашего REST API или нет.
Оба способа работают нормально. Я согласен с тем, что, строго говоря, одна из идей REST заключается в том, что вы должны использовать код состояния HTTP как часть вашего API (возвращайте 200 или 201 для успешной операции и 4xx или 5xx в зависимости от различных случаев ошибок). , полиции REST нет. Ты можешь делать, что хочешь. Я видел гораздо более вопиющие API, не относящиеся к REST, называвшиеся «RESTful».
На этом этапе (август 2015 г.) я рекомендую вам использовать код состояния HTTP как часть вашего API. Теперь при использовании фреймворков увидеть код возврата стало намного легче, чем раньше. В частности, теперь легче увидеть случай возврата не-200 и тело ответов не-200, чем это было в прошлом.
Код состояния HTTP является частью вашего API.
Вам нужно будет тщательно выбрать коды 4xx, которые соответствуют условиям вашей ошибки. Вы можете включить в качестве полезной нагрузки сообщение rest, xml или обычный текст, которое включает субкод и описательный комментарий.
Клиенты должны будут использовать программную структуру, которая позволит им получить код состояния уровня HTTP. Обычно выполнимо, но не всегда прямолинейно.
Клиенты должны будут различать коды состояния HTTP, указывающие на ошибку связи, и ваши собственные коды состояния, указывающие на проблему на уровне приложения.
Код состояния HTTP - это НЕ является частью вашего api
Код состояния HTTP всегда будет 200, если ваше приложение получило запрос, а затем ответило (как в случае успеха, так и в случае ошибки)
ВСЕ ваши ответы должны включать информацию «конверт» или «заголовок». status: # используйте любые коды, которые вам нравятся. Зарезервируйте код для успеха. msg: "ok" # Человеческая строка, отражающая код. Полезно для отладки. data: ... # Данные ответа, если они есть.
Этот метод может быть проще для клиентов, так как статус ответа всегда в одном и том же месте (субкоды не нужны), никаких ограничений на коды , нет необходимости получать код состояния уровня HTTP.
Вот сообщение с похожей идеей: http://yuiblog.com/blog/2008/10/15/datatable-260-part-one /
Основные проблемы:
Обязательно укажите номера версий, чтобы позже можно было изменить семантику API, если это необходимо.
Документ ...
Помните, что кодов состояния больше, чем указано в RFC HTTP / 1.1, реестр IANA находится по адресу http: // www. iana.org/assignments/http-status-codes. В случае, если вы упомянули код состояния 507.
Не забывайте также об ошибках 5xx для ошибок приложений.
В этом случае как насчет 409 (Конфликт)? Это предполагает, что пользователь может решить проблему, удалив сохраненные ресурсы.
В противном случае 507 (не совсем стандартный) также может работать. Я бы не стал использовать 200, если вы не используете 200 для ошибок в целом.
Есть два вида ошибок. Ошибки приложения и ошибки HTTP. Ошибки HTTP предназначены только для того, чтобы ваш обработчик AJAX знал, что все прошло нормально, и не должны использоваться ни для чего другого.
5xx Ошибка сервера
500 Internal Server Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout
505 HTTP Version Not Supported
506 Variant Also Negotiates (RFC 2295 )
507 Insufficient Storage (WebDAV) (RFC 4918 )
509 Bandwidth Limit Exceeded (Apache bw/limited extension)
510 Not Extended (RFC 2774 )
2xx Успех
200 OK
201 Created
202 Accepted
203 Non-Authoritative Information (since HTTP/1.1)
204 No Content
205 Reset Content
206 Partial Content
207 Multi-Status (WebDAV)
Однако то, как вы создаете ошибки приложения, зависит от вас. Например, переполнение стека отправляет объект с ответом , , данными и свойства сообщения . Ответ, на мой взгляд, содержит истина или ложь , чтобы указать, была ли операция успешной (обычно для операций записи). Данные содержат полезную нагрузку (обычно для операций чтения), а сообщение содержит любые дополнительные метаданные или полезные сообщения (например, сообщения об ошибках, когда ответ является ложным ).
Если клиентская квота превышена, это ошибка сервера, избегайте 5xx в этом случае.