为什么我们应该使用REST？ [英] Why we should use REST?

问题描述

如果我只用post和get请求完成我的工作，为什么要使用REST？

Why should I use REST if I can get my job done with only post and get requests?

推荐答案

Roy Fielding博客对于伪装成REST的RPC 感到沮丧。

Roy Fielding blogged with some frustration about RPCs masquerading as REST.

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

REST demands the use of hypertext, which scales very well since the client and server are very loosely coupled. With REST, the server is free to change the exposed resources at will. There is no fixed API above and beyond what REST itself defines. The client needs only know the initial URI, and subsequently chooses from server-supplied choices to navigate or perform actions. A server may download code to the client which aids in navigation and state representation.

所有这些都与各种远程过程调用（RPC）方案形成鲜明对比。客户端和服务器必须就通常需要编译到两端的详细协议达成一致（例如，在一个极端以特定顺序访问的特定表单的URI，另一个极端的SOAP / WSDL / WS *）。这种方法很脆弱，因为任何更改都需要同时在服务器端和客户端上实现。随着服务器和/或客户端数量的增长，它会迅速变得无法维持。服务器尤其受到影响，因为随着流行度的增加，发布的API的演变变得越来越困难。

All of this is in stark contrast with the various remote procedure call (RPC) schemes in which the client and server must agree upon a detailed protocol that typically needs to be compiled into both ends (e.g. URIs of a particular form accessed in a particular order at one extreme, SOAP/WSDL/WS* at the other). This approach is brittle, because any changes need to implemented on both the server and client sides at the same time. It rapidly becomes untenable as the number of servers and/or clients grows. Servers in particular suffer because evolution of the published API becomes progressively more difficult as popularity increases.

鉴于这些因素，REST在可能的情况下始终是更好的选择。它允许服务器的快速发展，并允许天文数量的应用程序在临时基础上自由交互（例如整个互联网）。

In light of these factors, REST is always the better choice when possible. It allows for rapid evolution of servers and allows an astronomical number of applications to interact freely on an ad hoc basis (e.g. the whole Internet).

但是什么时候可能的部分？当循环中有人时，REST效果最佳。毕竟，人类很有可能在提出以前未知的选项时做出理性选择。机器还没有。 Web RPC协议的诞生正是为了将双方手铐都固定在一个固定的协议上。这样，当人从图片中移除时，自动化过程更容易进行通信。当纯粹的自动化操作比进化和可扩展性更重要时（在互联网时间和互联网规模上），RPC是一种有效的设计选择。

But what about the "when possible" part? REST works best when there is a human in the loop. After all, a human has a good chance of being able to make a rational choice when presented with a previously unknown set of options. Machines aren't there yet. Web RPC protocols were born precisely to handcuff both sides to a fixed protocol. This makes it easier for automated processes to communicate when the human is removed from the picture. An RPC is a valid design choice when purely automated operation is more important than evolution and scalability (in Internet time and on an Internet scale).

规模和耦合？

这里的比例是指广义的意思。它包括用户和会话的数量，是的，还包括应用程序大小和开发过程。紧耦合对应用尺寸造成严重阻碍。如果没有REST架构提供的极其松散的耦合，很难想象存在最大的已知应用程序万维网。全球数百万开发人员已经合作构建了支持数十亿用户的应用程序。然而，开发人员这样做，同时仍然没有意识到彼此（或者至少如果它不是StackOverflow，他们将不会彼此意识到。）。

"Scale" here is meant in a broad sense. It includes numbers of users and sessions, yes, but also application size and development process. Tight coupling presents a severe impediment to application size. It is hard to imagine the existence of the largest known application, the World-Wide Web, without the extremely loose coupling afforded by the REST architecture. Millions of developers around the globe have collaborated to build this application that supports billions of users. Yet the developers do this while remaining blissfully unaware of each other (or at least they would be unaware of each other if it weren't for StackOverflow ;).

主要REST的启用原则是超文本。该架构的其他元素存在以非常大规模（在任何意义上）支持该原则。 REST是唯一可以想象的Web构建方式吗？不，但它恰好是事实上成功的标准。它应该是生态系统中任何新条目的默认选择，只有在仔细和明确的设计考虑之后才会被丢弃。

The primary enabling principle of REST is hypertext. The other elements of the architecture exist to support that principle in very large scale (in every sense). Is REST the only conceivable way that the Web could have been built? No. But it happens to be the wildly successful de facto standard. It should be the default choice for any new entry into the ecosystem, discarded only after careful and explicit design consideration.

这篇关于为什么我们应该使用REST？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！