如果我们不遵循RESTful最佳实践，会出现什么问题？

TL；DR：向下滚动到最后一段。

在定义RESTful API时，有很多关于最佳实践的讨论：支持什么HTTP方法、在每种情况下使用哪个HTTP方法、返回哪个HTTP状态代码、何时在查询字符串中传递参数、何时在路径中传递参数、何时在内容体中传递参数、何时在标题中传递参数、如何进行版本控制、结果集限制、分页等

如果你已经下定决心要使用最佳实践，那么关于做任何事情的最佳实践有很多问题和答案。不幸的是，为什么要首先使用最佳实践似乎没有问题（也没有答案）

大多数最佳实践指南都指导开发人员遵循最小意外原则，在正常情况下，这是遵循这些原则的充分理由。不幸的是，HTTP上的REST是一个反复无常的标准，如果不密切参与，就不可能实现它的最佳实践，而密切参与的缺点是，最终您的应用程序往往与特定的传输机制紧密绑定。因此，一些人（像我一样）正在争论“最小惊喜”的好处是否证明了将应用程序与REST放在HTTP问题上的缺点是合理的

作为最佳实践的替代方案，另一种不同的方法表明，为了从A点到B点获得应用程序定义的有效负载，我们对HTTP的参与应限于最低限度。根据这种方法，您在整个应用程序中只使用一个REST入口点URL，您永远不会使用HTTP POST以外的任何HTTP方法，永远不会返回HTTP 200 OK以外的任何HTTP状态代码，也永远不会以除请求的特定于应用程序的有效负载之外的任何方式传递任何参数。请求将无法传递，在这种情况下，web服务器负责向客户端返回“HTTP 404 Not Found”，或者请求将成功传递，在这种情况下，就传输协议而言，请求的传递是“HTTP 200 OK”，从这一点上讲，任何可能出错的事情都完全是应用程序的问题，与传输协议无关。显然，这种方法有点像是说“让我告诉你在哪里坚持你的最佳实践”

现在，还有其他声音说事情没有那么简单，如果你不遵循RESTful的最佳实践，事情就会破裂

---

例如，在未经授权的访问事件中，您应该返回实际的“HTTP 401 unauthorized”（而不是包含json序列化UnauthorizedException的成功响应），因为在收到401后，浏览器将提示用户凭据。当然，这并不是真的成立，因为REST请求不是由人类用户使用的浏览器发出的

另一种更复杂的方式是，通常在客户机和服务器之间存在代理，这些代理检查HTTP请求和响应，并试图从中获得意义，以便以不同的方式处理不同的请求。例如，他们说，在客户机和服务器之间的某个地方可能有一个缓存代理，它可以将对完全相同URL的所有请求视为相同的，因此可以缓存。因此，路径参数是区分不同资源所必需的，否则缓存代理可能只向服务器转发一次请求，然后将缓存响应返回给所有客户端。此外，该缓存代理可能需要知道某个请求-响应交换由于诸如“权限被拒绝”之类的特定错误而导致失败，以便再次不缓存该响应，否则导致临时错误的请求可能永远用缓存的错误响应来响应

因此，我的问题是：

---

除了“熟悉”和“最少惊讶”，还有什么其他好的理由可以遵循REST最佳实践？这些关于代理的担忧是真的吗？缓存代理真的如此愚蠢以至于缓存REST响应吗？是否很难配置代理以不那么愚蠢的方式运行？将代理配置为不那么愚蠢的方式是否存在缺点？

值得考虑的是，您所建议的是HTTP API过去15年左右的设计方式。这些天来，API设计师倾向于放弃这种方法。他们确实有自己的理由

如果您想避免在HTTP上使用RES:

，请考虑一些要点。

• HTTP上的ReST是HTTP/S传输机制的有效使用。避免使用ReST范式可能会导致每个请求/响应都被包装在冗长的信封中。SOAP就是一个例子

• ReST通过将应用程序语义放入标准机制（HTTP和XML/JSON（或其他数据格式）来鼓励客户机和服务器解耦。这些协议和标准得到了标准库的良好支持，并且是在多年的经验基础上建立起来的。当然，您可以用200状态码创建自己的“未经授权”响应主体，但ReST框架只是让它变得不必要，为什么还要麻烦呢

• ReST是一种设计方法，它鼓励您对分布式系统的视图进行关注，将重点放在数据上，而不是功能上，这已经被证明是构建分布式系统的一种有用机制。避免ReST存在着将重点放在类似RPC的机制上的风险，这些机制本身也有一些风险：
  • 它们可以变得非常细粒度和“健谈”
  • 这可能是对网络带宽的低效利用
  • 通过引入状态和时间耦合，实现了客户端和服务器的紧密耦合