为什么我们应该使用REST？
为什么我应该使用REST，如果我只能通过发布和获取请求完成我的工作？
罗伊·菲尔丁（Roy Fielding）对RPC伪装成REST感到沮丧。
REST要求使用超文本，由于客户端和服务器之间的耦合非常松散，因此可以很好地扩展。 使用REST，服务器可以随意更改公开的资源。 上面没有固定的API，超出了REST本身的定义。 客户端只需要知道最初的URI，然后从服务器提供的select中select导航或执行操作。 服务器可以将代码下载到客户端，这有助于导航和状态表示。
所有这些与各种远程过程调用（RPC）scheme形成鲜明对比，其中客户端和服务器必须就通常需要被编译到两端的详细协议达成一致（例如，以特定顺序访问的特定forms的URI在另一个极端，另一个是SOAP / WSDL / WS *）。 这种方法很脆弱，因为在服务器端和客户端都需要同时进行任何更改。 随着服务器和/或客户数量的增长，它迅速变得站不住脚。 服务器尤其受到损害，因为随着知名度的提高，发布的API的演变变得越来越困难。
鉴于这些因素，REST在可能的情况下始终是更好的select。 它允许服务器的快速发展，并允许天文数量的应用程序在临时的基础上（例如整个互联网）自由地进行交互。
但是，如果可能的话呢？ 当循环中有人时，REST效果最好。 毕竟，一个人有一个很好的机会能够作出一个理性的select时，提出了一个以前未知的选项。 机器还没有。 Web RPC协议的诞生正是为了将双方都固定在一个固定的协议上。 这使得人们从图片中移除时，自动化stream程更容易进行交stream。 当纯粹的自动化操作比进化和可扩展性更重要时（在Internet时间和Internet规模上），RPC是一个有效的deviseselect。
规模和耦合？
这里的“规模”是广义的意思。 它包括用户和会话的数量，是的，还包括应用程序的大小和开发过程。 紧耦合严重阻碍了应用的大小。 如果没有REST体系结构提供的非常松散的耦合，很难想象最大的已知应用程序World-Wide Web的存在。 全球数百万的开发者已经合作build立了这个支持数十亿用户的应用程序。 然而，开发人员这样做，而保持幸福不知道对方（或者至less他们将不知道对方，如果它不是为了StackOverflow;）。
REST的主要使能原则是超文本。 架构的其他要素是以非常大规模（从任何意义上）支持这个原则。 REST是networking可以build立的唯一可以想象的方式吗？ 不，但恰巧是成功的事实标准。 它应该是任何新进入生态系统的默认select，只有在仔细和明确的devise考虑之后才会被丢弃。
正确使用REST可以帮助您的系统组件保持正确的解耦，并且在将来可以更容易地进化，而不是像典型的RPC一样将它们直接绑定在一起。 这是您必须根据您的应用程序需求进行的架构select。 其他人已经注意到了一些技术上的好处，他们也应该被考虑到。
REST允许简单的APIdevise演变。 这就是REST的关键 – 你正在创build一个API。 有些评论涉及到这个思想的一些方面，但实际上并没有把核心问题带入现实。 当你正在处理REST时，你正在创build一个将被客户端（或你自己）使用的API。 资源上的HTTP操作为客户端提供了清晰的APIdevise和function指示。 因此，当我们正确使用正确的HTTP动词时，我们正在声明一个从客户端angular度来看是标准化和可理解的API。
你为什么认为只使用POST和GET意味着它不是REST？
指向REST的是每个“资源”都有一个资源标识符，一个URI。 每个URI 可能具有GET POST，PUT，DELETE。
- GET得到
- POST是更新
- PUT是创build
- 删除是删除。
如果你没有做这些事情 – 比如说PUT是一种罕见的和潜在的安全漏洞 – 那么你就不这样做。
如果您的GET请求不是幂等的，那么您的服务器和客户端之间的HTTPcaching将会破坏您的应用程序。 根据定义， POST请求不是幂等的，所以HTTPcaching不会caching这些请求和结果：在不中断应用程序协议的情况下，仍然可以获得cachingGET请求的好处。 巨大的成功。
而且，如果您需要删除对象， DELETE将比在POST请求中执行删除操作更容易在连线和日志中进行读取。 但是，网页浏览器不能轻易地用DELETE动词做出HTTP请求，所以对于你自己编程的客户来说更是如此。
在REST中发现要容易得多。 我们拥有WADL文档（类似于传统Web服务中的WSDL），可以帮助您向世界宣传您的服务。 您也可以使用UDDI发现。 用传统的HTTP POST和GET人们可能不知道你的消息请求和响应模式来打电话给你。
您应该使用REST，因为它实际上包含了您希望对资源/对象执行的所有可能操作。
- GET – 根据给定的条件检索资源
- POST – 创build资源
- PUT – 用给定的更新属性更新资源
- 删除 – 删除资源
另一个原因是，这是每个人都可以实施和使用的标准。 为了了解标准化的重要性，我build议阅读这个和这个 （这很有趣，但是确实有助于人们理解REST的概念）。
