我应该自己编写HTTP状态代码吗？（如Twitter 420：增强您的冷静）

我目前正在实现HTTP API，这是我的第一次。

我已经花了很多时间在Wikipedia页面上查看HTTP状态代码，因为我决心在正确的情况下实现正确的代码。在该页面上列出的是编号为420的代码，这是Twitter用来限制速率的自定义代码。

但是，已经存在用于速率限制的代码。是429。

这使我想知道为什么在已经存在用例的情况下，他们为什么要设置自定义的呢？那只是可爱吗？如果是这样，那么在什么情况下可以接受返回不同的状态代码，客户可能会遇到什么问题呢？

我在某个地方读到Mozilla并未实现笑话418: I’m a teapot响应，这使我认为客户端选择了他们实现的状态代码。如果这是真的，那么我可以想象Twitter的有趣之处可以增强您的冷静代码带来的麻烦。

除非我弄错了，否则我们可以使用任何代码号来表示我们喜欢的任何东西，并且只有约定表明404表示未找到，而429表示则很容易。

整个Internet建立在约定之上。我们称它们为RFC。如果没有人违反RFC，没有人会逮捕您，但是您却冒着服务无法与世界其他地方进行互操作的风险。如果发生这种情况，您将冒着创业公司无法吸引任何客户，业务受到负面报道，股东反抗，永久被解雇等风险。

HTTP状态代码具有自己的IANA注册表，每个注册表都可以追溯到定义它的RFC（或者在某些情况下为ID）。

在Twitter奇怪的420状态代码与RFC 6585中定义的标准429状态代码的特殊情况下，最有可能的解释是后者是最近才定义的。RFC的日期为2012年4月。我们看到Twitter 在其API 的先前不推荐使用的版本1中仅使用420；当前的API版本1.1实际上使用429状态代码。因此很明显，Twitter为此需要状态码并定义了自己的状态码。一旦有一个标准的，他们就切换到它。

当然，最佳实践是尽可能遵守标准。阅读RFC时，几乎总是会找到“ MUST”和“ SHOULD”之类的词；这些在构建应用程序时具有特定含义，您可以在RFC 2119中找到它们。

这个问题深入探讨了这个问题。但事实是，尽管您可以从技术上创建所需的任何状态代码，但在传统的状态代码含义范围之外创建状态代码只会使您的API对其他人更加晦涩难懂。除非那是关键，否则您创建的API是如此的惊人，以至于每个人都乐于更改代码以跟随您的领导，所以到底有什么关系呢？

归结为：任何标准都可以被打破。但是，如果您破坏了它，这样做会带来什么收益或损失呢？

通常，在可以做些不同的事情但标准暗示标准的情况下，最好遵循这些标准，除非有非常强烈和令人信服的理由偏离已建立的标准。对于Twitter，420: Enhance Your Calm他们正在创建一个响应代码，清楚地表明他们所面临的独特情况。这会在不拒绝服务的情况下降低请求速度。