Сейчас многие проекты являются веб-проектами, до и после окончания разделения взаимодействие происходит только через спокойный интерфейс, и когда мы вернулись из запроса, код состояния, как его вернуть?
Прежде всего, каковы обычно используемые коды состояния http.
2XX (Код успешного завершения)
200 - OK
запрос выполнен
201 - Created
Документ успешно создан,Например, успешное добавление пользователя
202 - Accepted
Запрос принят, соответствующая операция может быть не выполнена. Это используется для фоновой работы,Асинхронные операции, такие как сжатие базы данных
4XX (Код ошибки клиента)
400 - Bad Request
Неверные параметры запроса (Например, вы должны передать параметр типа Number, но вы передаете строку), запрос не может быть понят сервером, и запрос может быть повторно отправлен после модификации
401 - Unauthorized
Текущий запрашивающий пользователь не авторизован,например не залогинился
403 - Forbidden
Текущий запрос отклонен.Например, проблема с правами доступа к файловой системе или несанкционированные операции (например, обычные пользователи пытаются получить список пользователей-администраторов)
404 - Not Found
Запрошенный ресурс не найден,Обычно URL неправильный
405 - Method Not Allowed
Запрошенный URL-адрес был запрошен с недопустимым типом HTTP-запроса.Например, только сообщение поддержки API, в то время как клиент использовал get
406 - Not Acceptable
Сервер не поддерживает запрошенный тип контента
413 - Request Entity Too Large
Тело запроса слишком велико для поддержки.Обычно это вызвано тем, что загруженный файл превышает лимит.
5XX (Server Error код состояния ошибки сервера)
500 - Internal Server Error
Указывает, что при выполнении запроса на сервере произошла ошибка.Возможно, ошибка на сервере или в приложении.
503 - Service Unavailable
Услуга недоступна и не может обработать запрос прямо сейчас.
какой код ошибки возвращается
Как правило, в restful API мы идентифицируем код состояния следующим образом:
1. 2xx: сервер получает запрос клиента и может выполнить
2. 4xx: Ошибка в данных, отправленных клиентом, и сервер не может их выполнить (клиент может отправить другой запрос после исправления ошибки)
3. 5xx: данные, отправленные клиентом, верны, но серверная сторона не может выполниться из-за ошибки (клиентская сторона не может предпринять никаких действий)
ноЯ также видел, как STATUS CODE возвращает 200, а затем сообщает пользователю запросить успех с помощью пользовательского кода в ответе.
{
"code": 10020,
"msg": "name不能为空"
}
Хотя у редиски и овощей есть свои предпочтения, лично я все же считаю, что для интерфейса REST статус на уровне HTTP должен использоваться для выражения успешности операции., Поскольку сетевое взаимодействие — это не только клиент и сервер, в середине будет много уровней узлов, если один из уровней имеет очень ортодоксальное понимание запроса статуса 200 и выполняет кэширование или другую обработку, тогда вы можете сидеть на воске. А так как это написание интерфейса, то лучше быть стандартным и не зарываться.
Так что для успешного запроса нужно вернуть 2ХХ, а для интерфейса 4ХХ можно сделать соответствующую инкапсуляцию
Код состояния должен возвращать 4XX, но вы можете вернуть код ошибки исключения в данных ответа (этот код ошибки является кодом ошибки бизнес-ошибки).В настоящее время вы можете согласовать с внешним интерфейсом, что означает этот код бизнес-ошибки , и вы можете дать пользователю соответствующую подсказку.
Формат возвращаемых данных
public class BaseResponse<T> {
// 业务异常码
private int code;
// 说明信息
private String msg;
// 需要封装返回的数据
private T data;
}
НапримерGET /api/users/1, данные, возвращаемые таким запросом, помещаются в поле данных.
{
"code":200,
"msg":"SUCCESS",
"data": {
"id":1095,
"name":"张三"
}
}
Для ошибок сбоя запроса (код состояния http 4XX) будут возвращены следующие данные
{
"code": 10030,
"msg": "id不存在"
}
Поддержка Spring для кода состояния Http
@ResponseStatus(HttpStatus.CREATED)
public BaseResponse addUser(UserParam userParam) {
return service.addUser(userParam);
}
непосредственно черезResponseStatusАннотация для указания возвращаемого кода ошибки. Конечно, это нормальная ситуация, как поступить в ситуации, когда параметр не проходит проверку или вызван другими бизнес-исключениями?
Есть два способа, первый - это класс ответственности в весеннее
public ResponseEntity<BaseResponse> addUser(UserParam userParam) {
if(validate(userParam)) {
return service.addUser(userParam);
}
return new ResponseEntity<>(ResponseUtil.fail(STATUS_INVALID_PARAM), HttpStatus.NOT_FOUND);
}
Вторым способом является обработчиком глобального исключения, если мы найдем, есть проблема над параметрами, передаваемыми клиентом, вы можете бросить исключение, а затем обрабатываться в едином глобальном интервале обтеснителей исключения в обслуживании в
@RestControllerAdvice
public class WebExceptionConfig {
@ExceptionHandler(InvalidParamException.class)
@ResponseStatus(HttpStatus.BAD_REQUEST)
public BaseResponse handleInvalidParamException(InvalidParamException e) {
return ResponseUtil.fail(STATUS_INVALID_PARAM, e.getMessage());
}
}
Суммировать
- В разных ситуациях возвращаются разные коды состояния. В случае неудачных запросов возвращайте 4XX, а код бизнес-исключения можно указать в возвращаемых данных.
- должны быть унифицированы
- Не позволяйте возвращаемому коду состояния влиять на вашу бизнес-логику
Обратите внимание, не потеряйтесь
Если вы считаете, что то, что я написал, нормально, пожалуйста, поставьте мне лайк, подпишитесь и поделитесь, это отличная мотивация для меня.
Публичный номер think123, вы можете прочитать его в первый раз.
прошлый обзор
И интервьюер взрывает набор реплик MongoDB вот так
Знание этих навыков проектирования MongoDB может повысить эффективность на 50%
Я провел неделю, читая исходный код Kafka Producer.
Интервьюер: Как реализовать LRU с LinkedHashMap