Чи варто складати власні коди статусу HTTP? (a la Twitter 420: Підвищити спокій)

Зараз я впроваджую HTTP API, мій перший.

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

Однак уже існує код для обмеження ставок. Це 429.

Це змусило мене замислитися, чому вони встановлять спеціальний, коли вже є випадок використання. Це просто мило? І якщо так, то за яких обставин було б прийнятним повернути інший код статусу, і що, якщо у нього можуть виникнути проблеми з клієнтами?

Десь я читав, що Mozilla не 418: I’m a teapotреагує на жарт , що змушує мене думати, що клієнти обирають, які коди статусу вони реалізують. Якщо це правда, то я можу уявити, що смішний твіттер Twitter посилює ваш спокійний код проблематичним.

Якщо я не помиляюсь, і ми можемо привласнити будь-яке кодове число, щоб воно означало все, що нам подобається, і це лише конвенція наказує, що 404 означає, що не знайдено, а 429 означає, що це легко.

Весь Інтернет побудований на конвенціях. Ми їх називаємо RFC. Хоча ніхто не прийде і не заарештує вас, якщо ви порушите RFC, ви ризикуєте, що ваша служба не буде взаємодіяти з рештою світу. І якщо це трапиться, ви ризикуєте, що ваш стартап не отримає клієнтів, ваш бізнес отримає погану пресу, ваші акціонери повстануть, ваше звільнення постійно і т.д.

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

У конкретному випадку дивного коду статусу Twitter у порівнянні зі стандартним кодом статусу 429, визначеним у RFC 6585 , найімовірнішим поясненням є те, що останній був визначений лише нещодавно; RFC датується квітнем 2012 року. Ми бачимо, що Twitter використовує лише 420 у попередній застарілій версії 1 свого API; поточна версія API 1.1 фактично використовує код статусу 429 . Тож зрозуміло, що Twitter потребував коду статусу для цього і визначив свій власний; як тільки стандартний був доступний, вони перейшли на нього.

Найкраща практика, звичайно, полягає в тому, щоб дотримуватися якомога більше стандартів. Читаючи RFC, ви майже завжди знайдете слова типу "ОБОВ'ЯЗКОВО" та "ДОЛЖНЕ"; вони мають конкретні значення під час створення програми, яку ви можете знайти в RFC 2119 .

Це питання трохи заглиблюється в питання. Але справа в тому, що ви можете технічно створювати будь-який код статусу, який хочете, створення коду статусу поза традиційною сферою значень коду статусу лише робить ваш API більш тупим і прихованим для інших. Якщо це не суть, і API, який ви створюєте, настільки дивовижний, що кожен із задоволенням змінить своє кодування, щоб слідувати вашим результатам, і що це все одно має значення?

Це зводиться до цього: будь-який стандарт може бути порушений. Але якщо ви порушите це, що ви отримуєте чи втрачаєте, роблячи це?

Загалом, у випадках, коли ви можете зробити щось інше, але стандарти передбачають стандарти, найкраще дотримуватися стандартів, якщо немає дуже вагомих та переконливих причин відмовлятися від встановлених стандартів. У випадку з Твіттером 420: Enhance Your Calmвони створюють код відповіді, який чітко говорить про унікальну ситуацію, з якою вони стикаються. Що сповільнює запити, не відмовляючи в обслуговуванні.