Question

在阅读了很多关于REST和SOAP之间差异的内容后，我得到的结论是REST只是HTTP的另一个词。有人可以解释REST添加到HTTP的功能吗？

注意：我不是在寻找REST与SOAP的比较。

更新：感谢您的回答。现在我已经清楚地知道REST只是一组关于如何使用HTTP的规则。因此，我发布了关于what the advantages of these conventions are的后续内容。

注意：我现在掌握REST的含义;作为Emil Ivanov备注，REST意味着使用HTTP的方式。但是，我不确定这是否值得一个自己的术语，我当然不会围绕它进行宣传。

Answer 1

不， REST 是 HTTP 应使用的方式。

今天我们只使用了一小部分HTTP协议的方法 - 即GET和POST。 REST的方法是使用所有协议的方法。

例如，REST规定使用DELETE来删除URI后面的文档（无论是文件，状态等），而使用HTTP，您会滥用GET或POST ...product/?delete_id=22查询{{1}}。

Answer 2

HTTP是一种用于通信的协议，通常用于与Internet资源或任何带有Web浏览器客户端的应用程序进行通信。

REST意味着您在设计应用程序时使用的主要概念是资源：对于您要执行的每个操作，您需要定义通常只执行CRUD操作的资源，这是一项简单的任务。为此，使用HTTP协议中使用的4个动词对4个CRUD操作非常方便（Get for Read，POST用于CREATE，PUT用于UPDATE，DELETE用于DELETE）。这与RPC（远程过程调用）的旧概念不同，在旧概念中，您有一组您希望通过用户调用执行的操作。如果您考虑如何在帖子上描述Facebook，使用RPC，您可以创建名为AddLikeToPost和RemoveLikeFromPost的服务，并管理它以及与FB帖子相关的所有其他服务，因此您不需要为Like创建特殊对象。使用REST，您将拥有一个Like对象，该对象将使用Delete和Create功能单独管理。它还意味着它将描述数据库中的单独实体。这可能看起来像一个小的差异，但这样的工作通常会产生更简单的代码和更简单的应用程序。使用该设计，大多数应用程序的逻辑在对象的结构（模型）中是显而易见的，与通常必须明确添加更多逻辑的RPC不同。

设计RESTful应用程序通常要困难得多，因为它要求您以简单的方式描述复杂的事物。仅使用CRUD函数描述所有功能是很棘手的，但在这样做之后，你的生活会变得更简单，你会发现你会编写更短的方法。

存在的另一个限制REST体系结构是在与客户端（无状态）通信时不使用会话上下文，这意味着所有信息都需要了解谁是客户端以及他想要的内容与Web消息一起传递。对函数的每次调用都是自描述的，之前没有与客户端的对话，可以在消息中引用。因此客户无法告诉你＆＃34;给我下一页＆＃34;由于您没有会话来存储上一页的内容以及您想要的页面类型，因此客户端必须说“我的名字是yuval”，请将第2页的特定帖子转到特定论坛＆＃34;。这意味着需要在通信中传输更多的数据，但要想一想找到从＆＃34;报告下一页＆＃34;函数反对＆＃34;在堆栈溢出＆＃34;中找到问题ID 2190836的第2页。

当然还有更多内容，但我认为这是茶匙中的主要概念。

Answer 3

REST不会向HTTP添加任何特定功能，但它是与HTTP一起开发的架构风格，并且最常用HTTP作为其应用层协议。

Answer 4

HTTP是一种应用程序协议。 REST是一组规则，在遵循这些规则时，您可以构建具有一组特定约束的分布式应用程序。

如果您正在寻找区分RESTful应用程序与任何HTTP应用程序的REST的最重要约束，我会说“自我描述”约束和超媒体约束（又称超媒体作为应用程序状态引擎（HATEOAS）））是最重要的。

自描述约束要求RESTful请求在用户意图中完全自我描述。这允许中间人（代理和缓存）安全地对消息采取行动。

HATEOAS约束是关于将您的应用程序转换为链接Web，其中客户端的当前状态基于其在该Web中的位置。这是一个棘手的概念，需要比现在更多的时间来解释。

Answer 5

不太......

http://en.wikipedia.org/wiki/Representational_State_Transfer

最初描述的是REST HTTP的上下文，但不限于此那个协议。 RESTful架构可以基于其他应用程序层协议（如果已经存在）提供丰富而统一的词汇适用于基于转移的应用程序有意义的代表性国家。 RESTful应用程序最大限度地利用预先存在的，定义明确的界面和其他内置所选择的能力网络协议，并尽量减少添加新的特定应用程序最重要的功能。

http://www.looselycoupled.com/glossary/SOAP

（简单对象访问协议） Web服务消息的标准。 SOAP基于XML，定义了一个信封格式和各种规则描述其内容。见过（有 WSDL和UDDI）作为三者之一 Web服务的基础标准，它是首选的协议交换Web服务，但没有意味着唯一的; REST的支持者说它增加了不必要的复杂性。

Answer 6

据我所知，REST强制使用可用的HTTP命令，因为它们是用来实现的。

例如，我可以这样做：

GET
http://example.com?method=delete&item=xxx

但是休息时我会使用“DELETE”请求方法，不需要“方法”查询参数

DELETE
http://example.com?item=xxx

Answer 7

REST是一种接近大系统设计（如网络）的特定方式。

这是一套“规则”（或“约束”）。

HTTP是一种试图遵守这些规则的协议。

Answer 8

REST 不一定与 HTTP 相关联。 RESTful Web服务只是遵循RESTful架构的Web服务。

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Answer 9

REST =具象状态转移

REST 是一组规则，在遵循这些规则时，您可以构建具有一组特定约束的分布式应用程序。

REST 是一种交换任何（XML，JSON等）消息的协议，可以使用HTTP传输这些消息。

功能

它是无状态的，这意味着理想情况下客户端和服务器之间不应保持连接。客户端负责将其上下文传递给服务器，然后服务器可以存储该上下文以处理客户端的进一步请求。例如，服务器维护的会话由客户端传递的会话标识符标识。

无国籍状态的优点：

Web服务可以单独处理每个方法调用。

网络服务无需维护客户之前的互动。

这反过来简化了应用程序设计。

HTTP本身就是一种与TCP不同的无状态协议，因此RESTful Web服务可以与HTTP协议无缝协作。

无国籍状态的缺点：

需要在每个请求中添加一个标题形式的额外图层，以保留客户的状态。

为了安全起见，我们需要为每个请求添加标题信息。

REST支持的HTTP方法：

GET：/ string / someotherstring 它是幂等的，每次调用时理想情况下都应返回相同的结果

PUT：和GET一样。幂等，用于更新资源。

POST：应该包含网址和正文用于创建资源。理想情况下，多次调用应返回不同的结果，并应创建多个产品。

DELETE：用于删除服务器上的资源。

HEAD：

HEAD方法与GET相同，只是服务器不能在响应中返回消息体。响应HEAD请求的HTTP头中包含的元信息应该与响应GET请求时发送的信息相同。

OPTIONS：

此方法允许客户端确定与资源相关的选项和/或要求，或服务器的功能，而不会暗示资源操作或启动资源检索。

HTTP响应

Go here for all the responses。

以下是一些重要的内容： 200 - 好的 3XX - 客户端和URL重定向所需的其他信息 400 - 不良请求
401 - 未经授权访问
403 - 禁止
请求有效，但服务器拒绝操作。用户可能没有资源的必要权限，或者可能需要某种帐户。

404 - 未找到
找不到请求的资源，但将来可能会提供。客户的后续请求是允许的。

405 - 不允许的方法请求的资源不支持请求方法;例如，表单上的GET请求需要通过POST显示数据，或者在只读资源上显示PUT请求。

404 - 未找到请求
500 - 内部服务器故障
502 - 错误的网关错误

Answer 10

HTTP is a contract, a communication protocol and REST is a concept, an architectural style可能使用HTTP，FTP或其他通信协议，但广泛用于HTTP。

REST implies a series of constraints about how Server and Client should interact。 HTTP is a communication protocol with a given mechanism for server-client data transfer，它最常用于REST API，因为在定义REST之前REST was inspired by WWW (world wide web) which largely used HTTP，因此使用HTTP实现REST API样式更容易。

There are three major constraints in REST (but there are more):

1.服务器和客户端之间的交互只能通过超文本来描述。

2.服务器和客户端应该松散耦合，不要互相假设。客户端应该只知道资源入口点。交互数据应由响应中的服务器提供。

3.服务器不应存储有关请求上下文的任何信息。请求必须是独立的和幂等的（意味着如果同一请求无限重复，则检索到完全相同的结果）

HTTP只是一种可以帮助实现这一目标的通信协议（工具）。

有关详情，请查看以下链接：

https://martinfowler.com/articles/richardsonMaturityModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Answer 11

来自You don't know the difference between HTTP and REST

因此REST体系结构和HTTP 1.1协议彼此独立其他协议，但是HTTP 1.1协议被构建为遵循REST的原则和约束。一种看待 HTTP和REST之间的关系是REST是设计，并且 HTTP 1.1是该设计的实现。

Answer 12

REST API必须是超文本驱动的

从Roy Fielding's blog这里可以通过一系列方法来检查您是否正在构建HTTP API或REST API：

API设计人员在调用创建REST API之前请注意以下规则：


REST API不应该依赖于任何单个通信协议，尽管它成功映射到给定协议可能取决于元数据的可用性，方法的选择等。通常，任何使用URI的协议元素识别必须允许任何URI方案用于识别。 [这里的失败意味着识别不会与交互分开。]

除了填写或修复标准协议的未指定位的详细信息（例如HTTP的PATCH方法或链接头字段）之外，REST API不应包含对通信协议的任何更改。破解实现的解决方法（例如那些足以让人相信HTML定义HTTP方法集的浏览器）应该单独定义，或者至少在附录中定义，期望解决方法最终会过时。 [这里的失败意味着资源接口是特定于对象的，而不是通用的。]

REST API应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体定义扩展关系名称和/或启用超文本的标记类型。在媒体类型的处理规则的范围内（并且在大多数情况下，已经由现有媒体类型定义）应该完全定义用于描述在感兴趣的URI上使用什么方法的任何努力。 [失败在这里意味着带外信息正在推动交互而不是超文本。]

REST API不能定义固定资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须能够自由控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI，例如在HTML表单和URI模板中完成的。 [这里的失败意味着客户端由于带外信息而假定资源结构，例如特定于域的标准，这是面向数据的，与RPC的功能耦合等效。]

REST API永远不应具有对客户端有意义的“类型化”资源。规范作者可以使用资源类型来描述接口后面的服务器实现，但这些类型必须与客户端无关且不可见。对客户来说重要的唯一类型是当前表示的媒体类型和标准化的关系名称。 [同上]

应输入REST API，除了初始URI（书签）和适用于目标受众的标准化媒体类型集之外没有任何先验知识（即，任何可能使用API的客户都应该理解）。从那时起，所有应用程序状态转换必须由客户端选择服务器提供的选择来驱动，这些选择存在于接收的表示中或者由用户对这些表示的操纵所暗示。转换可以由客户端对媒体类型和资源通信机制的知识来确定（或限制），这两者都可以在运行中（例如，按需代码）进行改进。 [失败在这里意味着带外信息正在推动交互而不是超文本。]

HTTP和REST有什么区别？

12 个答案: