источник
Дело в том, что меня пригласили ответить на Жихуодин вопрос, в основном спрашивая, использовать ли статус 404, если идентификатор не найден. Мой ответ еще относительно ранний, и на тот момент было всего один или два ответа. Я подумал, что это не спорно.При обсуждении академических вопросов в академическом месте, конечно, надо соблюдать нормы.Через несколько часов я был в шоке. Самодельная кодовая партия имеет самый высокий уровень поддержки.К счастью, есть много 200-партийных партий, которые я обычно вижу не поддерживаемыми, иначе я бы действительно блевал кровью.
Зачем следовать кодексу
Большинство людей, которые говорят, что с особыми обстоятельствами следует обращаться особым образом и не придерживаться нормы, в основном потому, что они не понимают определенных знаний, и они используют это предложение как оправдание своей лени. На самом деле в общих проектах не так уж и много частных случаев.
Для лучшей адаптации к различным библиотекам
Большинство полных библиотек запросов HTTP будут разработать процесс обработки ошибок в соответствии с спецификацией RFC. Хотя методы обработки различны, часть обработки ошибок определенно будет объяснена в документе. Использование стандарта RFC может максимизировать совместимость с различными клиентами HTTP. Вы сказали, что клиент HTTP, который вы используете сейчас, не обрабатывает код состояния, но вы не можете гарантировать, что он не будет рефактирован в будущем, и он не будет обработан во время рефакторинга.
Как правило, вероятность обращения к API для использования js или python относительно высока.Давайте рассмотрим известные библиотеки. В js популярные в последнее время аксиомы по умолчанию классифицируют код за пределами 200-й серии как исключения. В python самым популярным http-клиентом являются запросы, которые более подробно обрабатывают код состояния.
Для разработчиков, чтобы лучше начать работу
Кроме того, с точки зрения управленческой команды, наш принцип заключается в том, чтобы свести к минимуму «нормы» проекта, чтобы им было легче следовать. Там, где можно использовать стандарты, не устанавливайте самостоятельно более сложное правило. Будь то мейнтейнер сервера или потребитель API, будут замены, и каждый, кто войдет в проект, будет знаком с множеством ненужных пользовательских спецификаций проекта.
Чем проще обратиться к большому заводу
На самом деле, чтобы задать техническое задание на проект, самое ненадежное дело - выстрелить себе в голову. Чуть лучше спросить у Жиху или на форумах. Лучше зайти в гугл для поиска. Проще всего сразу зайти на сайт продукты или спецификации основных производителей. API является общедоступной вещью, есть ли лучшая ссылка, чем эта? Давайте взглянем:
- Googleсоответствовать норме
- Githubсоответствовать норме
- MicrosoftСледуйте спецификациям Кстати, спецификации Microsoft API действительно поучительны.
- Twitterсоответствовать норме
- Али Клаудсоответствовать норме
- Tencent Cloud не соответствует всем 200 нормам, на самом деле технология Tencent более запутанна, и каждый проект отличается. Однако унифицированная спецификация, которая должна выполняться, заключается в том, что все коды ошибок в возвращаемом значении указывают на ошибки.
- Облако Байдусоответствовать норме
Мой совет
Может быть, многие люди с очень простой веб-структурой, приводящие к неправильному признаку, что возвращает код ошибки, он не может вернуться к телу ответа. На самом деле, вы возвращаетесь вне любого кода 204 состояния, лучшие доходы сопровождаются телом.
{
"error": "UserNotFound",
"message": "该用户没有找到"
}
Эта ошибка разделена на три уровня, первый уровень — это код состояния, пользователи могут примерно понять, в чем проблема. Второй уровень ошибки — это ключ, который использует согласованный английский язык без пробелов, чтобы пользователь мог выносить суждения, и пользователь может настроить следующую операцию в соответствии с ключом. Третий уровень — это сообщение. Некоторые ключевые пользователи могут решить отображать сообщение непосредственно конечному клиенту.
Если это проект микрослужбы, необходимо требовать, чтобы каждая служба объединяла ошибки таким образом, независимо от используемого языка. Если разработчик говорит вам, что фреймворк его не поддерживает, значит, он нехороший фреймворк и его нужно рефакторить. Хороший фреймворк позволяет не только настраивать содержимое ошибки, но также позволяет настраивать так называемый «возврат собственной ошибки фреймворка». Например, маршрут не найден и так далее.
Наконец
Я действительно не понимаю, почему самый дерьмовый ответ - сделать один600Код состояния может быть проголосован в первую очередь. Есть ли у пользователей Zhihu какой-либо независимый дух суждения?Пока они притворяются серьезными и демонстрируют некоторую квалификацию, даже если это ерунда, это всем понравится. Может действительно не подходит для ответов на технические вопросы по Жиху.