使用REST而不是非REST HTTP有什么好处？

时间：2010-02-03 09:55:01

标签： rest

显然，REST is just a set of conventions about how to use HTTP。我想知道这些惯例提供了哪些优势。有人知道吗？

14 个答案:

答案 0 :(得分：151)

我认为你不会得到一个好的答案，部分是因为没有人真正同意REST 是什么。 wikipedia page在流行语和解释上很重要。讨论页面值得一试，只是为了看看有多少人不同意这一点。据我所知，REST意味着：

我们尝试让URL识别资源，然后使用HTTP操作{而不是随机命名的setter和getter URL，并对所有getter使用GET，而对所有setter使用POST。 {1}}，GET，POST和PUT向他们提供内容。而不是

DELETE

你会做

GET /get_article?id=1
POST /delete_article   id=1

然后GET /articles/1/ DELETE /articles/1/ 和POST对应于“创建”和“更新”操作（但没有人同意这种方式）。

我认为缓存参数是错误的，因为查询字符串 通常是缓存的，除此之外你不需要使用它们。例如，django很容易做到这一点，我不会说它是REST：

PUT

甚至只需在网址中加入动词：

GET /get_article/1/
POST /delete_article/     id=1

在这种情况下，GET /read/article/1/ POST /delete/article/1/ POST /update/article/1/ POST /create/article/ 表示没有副作用的内容，GET表示更改服务器上的数据的内容。我认为这可能更清晰，更容易，尤其是因为你可以避免整个POST - vs - PUT这件事。另外，如果您愿意，可以添加更多动词，因此您不会被人为地绑定到HTTP提供的内容。例如：

POST

（或者其他什么，在它们发生之前很难想到这些例子！）

总而言之，我只能看到两个优点：

  1. 您的网络API可能更清晰，更易于理解/发现。
  2. 在与网站同步数据时，使用REST可能更容易，因为您可以说POST /hide/article/1/ POST /show/article/1/ 或其他什么。这在很大程度上取决于您的代码。

    3. 但是我觉得有一些很大的缺点：

    1. 并非所有操作都能轻松映射到CRUD（创建，读取/检索，更新，删除）。您甚至可能不会处理对象类型资源。
    2. 为可疑的利益付出了额外的努力。
    3. 关于synchronize("/articles/1/")和PUT的回合的混淆。在英语中，它们意味着类似的东西（“我将在墙上发布/发布通知。”）。

      4. 总而言之，我会说：除非您真的想要付出额外的努力，或者如果您的服务非常适合CRUD操作，请为您的第二版API保存REST。

      我刚刚遇到了REST的另一个问题：在一个请求中执行多个操作并指定要获取的复合对象的哪个部分并不容易。这在移动设备上尤为重要，因为往返时间可能很长并且连接不可靠。例如，假设您在Facebook时间线上收到帖子。 “纯粹的”REST方式类似于

      POST

      哪种有点荒谬。 Facebook的API非常棒IMO，所以让我们看看他们做了什么：

        

      默认情况下，进行查询时会返回大多数对象属性。   您可以选择要返回的字段（或连接）   “fields”查询参数。例如，此URL仅返回   本的名字，名字和图片：   https://graph.facebook.com/bgolub?fields=id,name,picture

      我不知道你怎么用REST做这样的事情，如果你做了它是否仍然算作REST。我肯定会忽略那些试图告诉你你不应该这样做的人（特别是如果原因是“因为它不是REST”）！

答案 1 :(得分：43)

简而言之，REST意味着使用HTTP的方式。

看看Roy Fielding's dissertation about REST。我认为每个进行Web开发的人都应该阅读它。

作为一个说明，Roy Fielding也是HTTP协议背后的关键驱动因素之一。

列举一些优点：

  • 简单。
  • 您可以充分利用HTTP缓存和代理服务器来帮助您处理高负载。
  • 它可以帮助您将非常复杂的应用程序组织成简单的资源。
  • 它使新客户可以轻松使用您的应用程序，即使您没有专门为他们设计（可能是因为他们在您创建应用程序时不在身边）。

答案 2 :(得分：27)

简单地说：无。

欢迎使用downvote，但我仍然认为与非REST HTTP相比没有任何实际好处。所有当前答案均无效。来自当前投票最多的答案的论据：

  • 简单。
  • 您可以充分利用HTTP缓存和代理服务器来帮助您处理高负载。
  • 它可以帮助您将非常复杂的应用程序组织成简单的资源。
  • 它使新客户可以轻松使用您的应用程序，即使您没有专门为他们设计（可能是因为他们在您创建应用程序时不在身边）。

1。简单

使用REST，您需要为服务器端和客户端脚本添加额外的通信层=＆gt;它实际上比使用非REST HTTP更复杂。

2。缓存

缓存可以由服务器发送的HTTP标头控制。 REST不会添加非REST中缺少的任何功能。

3。组织

REST不会帮助组织事情。 强制您使用您正在使用的服务器端库支持的API。使用非REST方法时，可以以相同的方式（或更好）组织应用程序。例如。请参阅Model-View-Controller或MVC routing。

4。易于使用/实施

根本不是真的。这一切都取决于您组织和记录您的应用程序的程度。 REST不会神奇地使您的应用程序更好。

答案 3 :(得分：21)

恕我直言，REST支持的最大优势是减少客户端/服务器耦合。在不破坏现有客户端的情况下，随着时间的推移发展REST接口要容易得多。

答案 4 :(得分：12)

可发现

每个资源都有对层次结构或链接中其他资源的引用，因此可以轻松浏览。这对于开发客户的人来说是一个优势，使他/她不必经常咨询文档并提供建议。这也意味着服务器可以单方面更改资源名称（只要客户端软件不对URL进行硬编码）。

与其他工具的兼容性

您可以通过CURL进入API的任何部分，或使用Web浏览器导航资源。使调试和测试集成更加容易。

标准化动词名称

允许您指定操作，而无需搜索正确的措辞。想象一下，如果OOP getter和setter没有标准化，有些人使用retrieve和define代替。您必须为每个单独的接入点记住正确的动词。知道只有少数动词可用的计数器有问题。

标准化状态

如果GET资源不存在，您可以确保在RESTful API中出现404错误。将它与非RESTful API进行对比，可以返回{error: "Not found"}包裹在上帝知道有多少层。如果您需要额外的空间来向另一方的开发人员写一条消息，您可以随时使用响应的主体。

实施例

想象一下两个具有相同功能的API，一个遵循REST而另一个不是。现在想象一下这些API的以下客户端：

的RESTful：

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP：

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

现在想一想以下问题：

  • 如果每个客户的第一次电话有效，那么你能确定其余部分的确定吗？

  • 对API进行了重大更新，可能会也可能没有更改这些访问点。您需要重新阅读多少文档？

  • 您能预测最后一次查询的回复吗？

  • 您必须编辑发布的评论（删除之前）。你可以不检查文档吗？

答案 5 :(得分：9)

我建议你看看Ryan Tomayko的How I Explained REST to My Wife

第三方编辑

摘自waybackmaschine链接：

一个例子怎么样？你是老师，想管理学生：

  • 他们在哪个班级，
  • 他们得到的成绩，
  • 紧急联系人，
  • 有关您教授的书籍的信息等。

如果系统是基于网络的，那么这里涉及的每个名词都可能有一个URL：student, teacher, class, book, room, etc。 ...如果每个URL都有一个机器可读的表示，那么将新工具锁定到系统上将是微不足道的，因为所有这些信息都可以以标准方式使用。 ......你可以建立一个全国范围的系统，能够与每个学校系统交谈以收集测试分数。

每个系统都会使用简单的HTTP GET从彼此获取信息。如果一个系统需要向另一个系统添加内容，它将使用HTTP POST。如果系统想要在另一个系统中更新某些内容，它会使用HTTP PUT。唯一要弄清楚的是数据应该是什么样的。

答案 6 :(得分：4)

我建议所有正在寻找这个问题答案的人通过this "slideshow"。

我无法理解REST是什么以及为什么它如此酷，它的优点和缺点，与SOAP的差异 - 但这个幻灯片是如此精彩和易于理解，所以现在我比以前更清楚了

答案 7 :(得分：3)

缓存。

REST还有其他更深入的好处，它通过松耦合和超文本围绕进化能力，但缓存机制是你应该关心RESTful HTTP的主要原因。

答案 8 :(得分：2)

它写在Fielding dissertation中。但如果你不想读很多东西：

  • 提高了可扩展性（由于无状态，缓存和分层系统限制）
  • 解耦客户端和服务器（由于无状态和统一的接口限制）
    • 可重用客户端（客户端可以使用常规REST浏览器和RDF语义来决定要遵循的链接以及如何显示结果）
    • 非破坏客户端（客户端仅根据应用程序特定的语义更改中断，因为它们使用语义而不是某些API特定知识）

答案 9 :(得分：0)

  • 为每个“资源”提供一个ID
  • 将事物联系在一起
  • 使用标准方法
  • 具有多种表示形式的资源
  • 无国籍地沟通

可以通过POST和GET完成所有工作吗？是的，这是最好的方法吗？没有为什么？因为我们有标准方法。如果你再想一想，就可以用GET来做所有事情。那么我们为什么要打扰使用POST呢？因为标准！

例如，今天考虑一个MVC模型，你可以限制你的应用程序只响应特定类型的动词，如POST，GET，PUT和DELETE。即使在引擎盖下，一切都被模拟为POST和GET，为不同的动作设置不同的动词也没有意义吗？

答案 10 :(得分：0)

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

答案 11 :(得分：0)

一个优点是，我们可以非顺序处理XML文档并从不同的源解组XML数据，如InputStream对象，URL，DOM节点......

答案 12 :(得分：0)

@Timmmm，关于你的编辑：

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

这会大大减少通话次数

没有什么能阻止您设计一个接受HTTP参数的服务器来表示客户可能想要的字段值...

但这是一个细节。

更重要的是，您没有提到REST架构风格的巨大优势（更好的可扩展性，由于服务器无状态;更好的可用性，由于服务器无状态也;更好地使用标准服务，如例如，当使用REST架构风格时，缓存;客户端和服务器之间的耦合低得多，因为使用了统一的接口;等等。）

至于你的评论

  

“并非所有操作都能轻松映射到CRUD（创建，读取/检索，更新，   删除）。“

：RDBMS也使用CRUD方法（SELECT / INSERT / DELETE / UPDATE），总有一种方法可以表示数据模型并对其采取行动。

关于你的句子

  

“您甚至可能不会处理对象类型资源”

：RESTful设计本质上是一个简单的设计 - 但这并不意味着设计它很简单。你看得到差别吗 ？你需要考虑很多关于你的应用程序将代表和处理的概念，如果你愿意，必须做些什么，以便通过资源来表示它。但如果你这样做，你最终会得到一个更简单有效的设计。

答案 13 :(得分：-1)

搜索引擎可以忽略查询字符串。

相关问题
最新问题