WRe*_*ach 59
罗伊·菲尔丁(Roy Fielding)对于伪装成REST的RPC感到有些沮丧.
REST要求使用超文本,因为客户端和服务器非常松散地耦合,所以超文本可以很好地扩展.使用REST,服务器可以随意更改公开的资源.除了REST本身定义之外,没有固定的API.客户端只需要知道初始URI,然后从服务器提供的选项中选择导航或执行操作.服务器可以将代码下载到客户端,这有助于导航和状态表示.
所有这些与各种远程过程调用(RPC)方案形成鲜明对比,其中客户端和服务器必须就通常需要编译到两端的详细协议达成一致(例如,以特定顺序访问的特定表单的URI)在一个极端,SOAP/WSDL/WS*在另一个极端).这种方法很脆弱,因为任何更改都需要同时在服务器端和客户端上实现.随着服务器和/或客户端数量的增长,它会迅速变得无法维持.服务器尤其受到影响,因为随着流行度的增加,已发布的API的演变变得越来越困难.
鉴于这些因素,REST在可能的情况下始终是更好的选择.它允许服务器的快速发展,并允许天文数量的应用程序在临时基础上自由交互(例如整个互联网).
但那么"何时可能"呢？当循环中有人时,REST效果最佳.毕竟,人类很有可能在提供一组先前未知的选项时做出理性选择.机器还没有.Web RPC协议的诞生正是为了将双方手铐都固定在一个固定的协议上.这样,当人从图片中移除时,自动化过程更容易进行通信.当纯粹的自动化操作比进化和可扩展性(在Internet时间和Internet规模上)更重要时,RPC是一种有效的设计选择.
规模和耦合？
这里的"规模"是指广义的意思.它包括用户和会话的数量,是的,还包括应用程序大小和开发过程.紧耦合对应用尺寸造成严重阻碍.如果没有REST架构提供的极其松散的耦合,很难想象存在最大的已知应用程序万维网.全球数百万开发人员已经合作构建了支持数十亿用户的应用程序.然而,开发人员这样做,同时仍然没有意识到彼此(或者至少如果它不是StackOverflow,他们将不会彼此意识到;).
REST的主要使能原则是超文本.该架构的其他元素存在以非常大规模(在任何意义上)支持该原则.REST是否可以构建Web的唯一可行方式？不,但它恰好是事实上成功的标准.它应该是生态系统中任何新条目的默认选择,只有在仔细和明确的设计考虑之后才会丢弃.
正确使用REST可以帮助您的系统组件保持正确的分离,并且将来可以比以典型的RPC类方式将它们直接捆绑在一起更容易进化.这是您必须根据应用程序的需求进行的架构选择.其他人已经注意到一些技术上的好处,也应该考虑到它们.
REST允许轻松演化API设计.这是REST的关键 - 你正在创建一个API.一些评论涉及这一思想的各个方面,但实际上并未将核心问题付诸实践.在处理REST时,您正在创建一个供客户(或您自己)使用的API.资源上的HTTP操作向客户端提供了API设计和功能的明确指示.因此,当我们正确使用正确的HTTP谓词时,我们正在声明一个标准化且可从客户端角度理解的API.
| 归档时间： |
|
| 查看次数： |
57437 次 |
| 最近记录： |