问为什么我们应该使用REST？

EN

罗伊·菲尔丁在博客中表达了对RPCs masquerading as REST的一些不满。

REST需要使用超文本，因为客户端和服务器是非常松散耦合的，所以超文本的伸缩性非常好。使用REST，服务器可以随意更改公开的资源。在REST本身定义的基础上，没有固定的API。客户端只需要知道初始URI，然后从服务器提供的选项中选择导航或执行操作。服务器可以将代码下载到客户端，这有助于导航和状态表示。

所有这一切都与各种远程过程调用(RPC)方案形成了鲜明对比，在RPC方案中，客户机和服务器必须就一个详细的协议达成一致，该协议通常需要编译到两端(例如，一个极端以特定顺序访问的特定形式的URI，另一个极端是SOAP/WSDL/WS* )。这种方法很脆弱，因为任何更改都需要同时在服务器端和客户端实现。随着服务器和/或客户端数量的增加，它很快就变得站不住脚。服务器尤其受到影响，因为随着受欢迎程度的增加，发布的API的演变变得越来越困难。

考虑到这些因素，在可能的情况下，REST总是更好的选择。它允许服务器的快速发展，并允许天文数字的应用程序在特别的基础上自由交互(例如，整个互联网)。

但是“当可能的时候”这一部分又如何呢？当循环中有人类时，REST工作得最好。毕竟，当面对一组以前未知的选项时，人类很有可能做出理性的选择。机器还没有出现。Web RPC协议的诞生恰好是为了将双方都束缚在一个固定的协议上。这使得当人类被从图片中移除时，自动化过程更容易进行通信。当纯粹的自动化操作比演进和可伸缩性更重要时，RPC是一个有效的设计选择(在Internet时间和Internet规模上)。

规模和耦合？

这里的“规模”指的是广义的。它包括用户和会话的数量，是的，但也包括应用程序大小和开发过程。紧密耦合严重阻碍了应用程序的规模。如果没有REST架构提供的极端松散耦合，很难想象已知最大的应用程序--万维网的存在。全球数以百万计的开发人员合作构建了这个支持数十亿用户的应用程序。然而，开发人员在做这件事时却幸灾乐祸地彼此不知道(或者至少如果不是因为StackOverflow，他们就不会知道对方)。

REST的主要支持原则是超文本。体系结构的其他元素存在，以非常大的规模(在任何意义上)支持这一原则。REST是构建Web的唯一可能的方式吗？不是的。但它恰好是非常成功的事实上的标准。它应该是任何进入生态系统的新成员的默认选择，只有在仔细和明确的设计考虑之后才会放弃。

正确使用REST可以帮助您的系统组件保持适当的解耦，并且比起以典型的类似RPC的方式将它们直接绑定在一起，将来可以更容易地进行演化。这是一个架构选择，您必须根据应用程序的需求做出选择。其他人注意到了一些技术上的好处，它们也应该被考虑在内。

REST允许API设计的简单演变。这就是REST的关键所在--您正在创建一个API。有些评论触及了这一思想的各个方面，但实际上并没有将核心问题带入生活。当您处理REST时，您正在创建一个供客户端(或您自己)使用的API。资源上的HTTP操作为客户端提供了API设计和功能的明确指示。因此，当我们正确地使用正确的HTTP动词时，我们就声明了一个从客户端角度来看是标准化和可理解的API。