为什么我们应该使用REST？

Question

为什么我们应该使用REST？

httprest

70

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

- Jeg Bagus

3

请参阅使用REST而不是非REST HTTP的优势是什么？。 - WReach

8个回答

6

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

- Brian Kelly

6

REST允许API设计的轻松演进。这就是REST的关键之处 - 您正在创建一个API。一些评论提到了这种思想的某些方面，但实际上并没有将核心问题解释清楚。当您使用REST时，您正在创建一个将被客户端（或自己）使用的API。资源上的HTTP操作清晰地向客户端指示API的设计和功能。因此，当我们正确地使用HTTP动词时，我们正在声明一个从客户端角度标准化且易理解的API。

- blackpanther

3

你认为仅使用POST和GET就意味着不符合REST的理念吗？

REST的核心在于每个“资源”都有一个资源标识符，即URI。每个URI可能具有GET、POST、PUT、DELETE四种方法。

其中： - GET表示读取 - POST表示更新 - PUT表示创建 - DELETE表示删除

如果你没有使用其中一些方法，比如PUT很少用且有潜在安全风险，那么你就不符合REST的理念。

- Charlie Martin

2

试图将POST和PUT映射到更新和创建确实行不通。我同意REST并不要求使用所有方法，它只是说如果你使用其中一个，请确保正确使用它。 - Darrel Miller

23

我认为更准确的说法是，POST 是创建，而 PUT 是更新。 - Matthew

5

没有人能够达成一致意见关于POST和PUT的使用顺序，这就是我认为不要滥用HTTP的一个很好的理由。 - Timmmm

3

如果您的GET请求不是幂等的，那么服务器和客户端之间的HTTP缓存将会破坏您的应用程序。根据定义，POST请求不是幂等的，因此HTTP缓存不会缓存这些请求和结果：您仍然可以获得GET请求的缓存优势，而不会破坏您的应用程序协议。非常成功。

另外，如果您需要删除对象，DELETE在传输和日志中比执行删除操作的POST请求更容易阅读。但是，Web浏览器无法轻松地使用DELETE动词进行HTTP请求，因此它更适用于您自己编写的客户端。

- sarnold

3

由于以下特点和优点，您应该使用REST：

特点

1. 无状态客户端/服务器协议：每个HTTP包含运行所需的所有必要信息，这意味着客户端和服务器都不需要记住任何先前的状态来满足它。尽管如此，一些HTTP应用程序包括缓存存储器。这配置了所谓的无状态客户机-缓存服务器协议：可以将一些响应定义为可缓存的，以便客户端可以在未来对相同请求运行相同的响应。然而，该选项存在并不意味着它是最推荐的选择。

2. 在任何REST系统和HTTP规范中都有四个非常重要的数据交易：POST（创建），GET（读取和查询），PUT（编辑）和DELETE。

3. REST中的对象始终从URI中操作。在此REST系统中，唯一标识每个资源的是URI而不是其他元素。URI允许我们访问信息以更改或删除它，例如与第三方共享其确切位置。

4. 统一接口：为了传输数据，REST系统在资源上应用特定操作（POST，GET，PUT和DELETE），只要它们被标识为URI。这使得更容易获得统一的接口，用于系统化信息处理过程。

5. 分层系统：组件之间的分层体系结构。每个层在REST系统中具有一定的功能。

6. 使用超媒体：超媒体是Ted Nelson于1965年创造的一个术语，是超文本概念的扩展。将这个概念应用到网页开发中，就是允许用户通过HTML链接浏览对象集合。对于REST API来说，超媒体概念解释了应用程序开发接口提供适当链接以在数据上运行特定操作的能力。

优点

客户端与服务器之间的分离：REST协议完全将用户界面与服务器和数据存储分开。这在开发过程中具有一些优点。例如，它提高了界面对其他类型平台的可移植性，增加了项目的可扩展性，并允许开发的不同组件独立演变。
可见性、可靠性和可扩展性。客户端和服务器之间的分离有一个明显的优点，那就是每个开发团队都可以轻松地扩展产品。他们可以迁移到其他服务器或对数据库进行各种更改，只要每个请求的数据被正确发送。分离使前端和后端易于在不同的服务器上运行，从而使应用程序更加灵活。
REST API始终独立于平台或语言类型：REST API始终适应使用的语法或平台类型，这在更改或测试开发中的新环境时具有相当大的自由度。使用REST API，您可以拥有PHP、Java、Python或Node.js服务器。唯一必需的是，对请求的响应应始终以用于信息交换的语言进行，通常是XML或JSON。

来源

- Abhijeet Ashok Muneshwar

3

在REST中，发现（Discovery）更加容易。我们有WADL文档（类似于传统Web服务中的WSDL），可以帮助您向世界宣传您的服务。您也可以使用UDDI发现。对于传统的HTTP POST和GET，人们可能不知道您的消息请求和响应模式以调用您。

- Balaji

2

您应该使用REST，因为它真正涵盖了您想要在一个资源/对象上执行的所有潜在操作。

GET - 基于给定条件检索资源
POST - 创建一个资源
PUT - 使用给定的更新属性更新资源
DELETE - 删除一个资源

另一个原因是它是每个人都可以实现和使用的标准。如果想了解为什么标准化很重要，我建议阅读this和this（这非常有趣，但确实帮助人们掌握REST的概念）。

- Mike Lewis

2

这不是W3C标准。 - Jossie Calderon

POST和PUT并不一定对应创建和更新。有时候它们确实是这样的。但如果使用PUT最适合解决问题，那么使用PUT创建新资源也没有问题。然而，请求必须是安全可重复（幂等），如果是这样，应该使用PUT而不是POST。相反，如果您的更新请求不安全可重复，应该使用POST而不是PUT。 - morten

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- WReach · Accepted Answer

罗伊·菲尔丁（Roy Fielding）有些沮丧地在博客中谈到了RPC伪装成REST的问题。

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

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

考虑到这些因素，如果可能的话，REST总是更好的选择。它允许服务器快速演变，并允许天文数字的应用程序在自由的临时基础上相互交互（例如整个互联网）。

但是“可能时”的部分怎么办？当有人参与时，REST的效果最佳。毕竟，面对以前未知的选项集时，人类有很大机会能够做出理性选择。机器还没有那么智能。 Web RPC协议的诞生恰好是为了将双方都限制在固定的协议中。这使得自动化流程在去除人类因素的情况下进行通信更加容易。当纯自动化操作比进化和可扩展性（在互联网时间和互联网规模上）更重要时，RPC是一种有效的设计选择。

规模和耦合？

这里的“规模”是广义的。它包括用户和会话数量，应用程序大小和开发过程。紧密耦合对应用程序大小构成严重障碍。很难想象世界上已知最大的应用程序——万维网——没有REST架构提供的极松散的耦合。全球数百万开发人员合作构建了支持数十亿用户的此应用程序。然而，开发人员在保持彼此无意识的同时完成了这项工作（或者至少如果没有StackOverflow的话他们就会不知道彼此；）。

REST的主要启用原则是超文本。架构的其他元素存在于非常大规模（在各个方面）中以支持该原则。REST是Web可能被构建的唯一可考虑的方式吗？不是。但它恰好是极其成功的事实标准。对于生态系统中的任何新条目，它应该是默认选择，仅在经过仔细和明确的设计考虑后才放弃。