Должен ли я создать свои собственные коды состояния HTTP? (а-ля Твиттер 420: Повысьте спокойствие)

В настоящее время я реализую HTTP API, мой первый в истории.

Я тратил много времени, просматривая страницу Википедии с кодами состояния HTTP, потому что я полон решимости реализовать правильные коды для нужных ситуаций. На этой странице указан код с номером 420, который является пользовательским кодом, который Twitter использовал для ограничения скорости.

Хотя уже есть код для ограничения скорости. Это 429.

Это заставило меня задуматься, почему они устанавливают пользовательский, когда уже есть вариант использования. Это просто мило? И если да, то какие обстоятельства позволят вернуть другой код состояния, и что, если возникнут какие-либо проблемы с клиентами, могут возникнуть?

Я где-то читал, что Mozilla не реализует 418: I’m a teapotответ на шутку , что заставляет меня думать, что клиенты выбирают, какие коды состояния они реализуют. Если это правда, то я могу представить, что забавный маленький твиттер улучшил ваш спокойный код, создавая проблемы.

Если я не ошибаюсь, и мы можем присвоить любой номер кода для обозначения того, что нам нравится, и это единственное соглашение гласит, что 404 означает не найден, а 429 означает успокоиться.

Весь Интернет построен на условностях. Мы называем их RFC. Хотя никто не придет и не арестует вас, если вы нарушите RFC, вы рискуете, что ваша служба не будет взаимодействовать с остальным миром. И если это произойдет, вы рискуете, что ваш стартап не получит клиентов, ваш бизнес получит плохую репутацию, ваши акционеры возмутятся, вас уволят навсегда и т. Д.

Коды состояния HTTP имеют свой собственный реестр IANA , каждый из которых прослеживается до RFC (или, в одном случае, ID), который его определил.

В конкретном случае странного кода состояния 420 в Twitter по сравнению со стандартным кодом состояния 429, определенным в RFC 6585 , наиболее вероятным объяснением является то, что последний был определен только недавно; RFC датируется апрелем 2012 года. Мы видим, что Twitter использует только 420 в предыдущей устаревшей версии 1 своего API; текущая версия API 1.1 фактически использует код состояния 429 . Таким образом, ясно, что Twitter нуждался в коде статуса для этого и определял их собственный; как только стандартный был доступен, они переключились на него.

Лучшая практика, конечно, это придерживаться как можно более строгих стандартов. Когда вы читаете RFC, вы почти всегда найдете такие слова, как «MUST» и «SHOULD»; они имеют определенные значения при создании приложения, которые вы можете найти в RFC 2119 .

Этот вопрос немного углубляется в проблему. Но дело в том, что, хотя технически вы можете создать любой код состояния, какой захотите, создание кода состояния вне традиционной области значений кода состояния только делает ваш API более тупым и загадочным для других. Если не в этом суть, и API, который вы создаете, настолько удивителен, что каждый с радостью изменит свой код, чтобы следовать вашему примеру, так что это все равно имеет значение?

Это сводится к следующему: любой стандарт может быть нарушен. Но если ты сломаешь это, что ты получаешь или теряешь при этом?

В общем, в случаях, когда вы можете сделать что-то другое, но стандарты подразумевают стандарты, лучше придерживаться стандартов, если нет очень веской и убедительной причины отклоняться от установленных стандартов. В случае с Twitter 420: Enhance Your Calmони создают код ответа, который четко говорит об уникальной ситуации, с которой они сталкиваются. Что замедляет запросы, не отказывая в обслуживании.