HTTP和REST有什么区别？

Question

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

注意:我不是在寻找REST与SOAP的比较.

更新:感谢您的回答.现在我已经清楚地知道REST只是一组关于如何使用HTTP的规则.因此,我发布了关于这些惯例的优点的后续行动.

注意:我现在掌握了REST的含义; 正如Emil Ivanov所说,REST意味着使用HTTP的方式.但是,我不确定这是否值得一个自己的术语,我当然不会围绕它进行炒作.

Answer 1

不,REST是应该使用HTTP的方式.

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

例如,REST规定了DELETE擦除URI背后的文档(无论是文件,状态等)的用法,而使用HTTP,您会滥用GET或者POST像查询一样...product/?delete_id=22.

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帖子相关的所有其他服务,因此您不需要创建特殊的喜欢的对象.使用REST,您将拥有一个Like对象,该对象将使用Delete和Create功能单独管理.它还意味着它将描述数据库中的单独实体.这可能看起来像一个小的差异,但这样的工作通常会产生更简单的代码和更简单的应用程序.使用该设计,大多数应用程序的逻辑从对象的结构(模型)中显而易见,与RPC通常必须明确添加更多逻辑不同.

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

存在的另一个限制REST体系结构是在与客户端(无状态)通信时不使用会话上下文,这意味着所有信息需要了解谁是客户端以及他想要的内容与Web消息一起传递.对函数的每次调用都是自描述的,之前没有与客户端的对话,可以在消息中引用.因此,客户端无法告诉您"给我下一页",因为您没有会话来存储上一页和您想要的页面类型,客户端必须说"我的名字是yuval,get我在特定论坛的特定帖子的第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

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 was inspired by WWW (world wide web) which largely used HTTP在 REST 被定义之前，所以使用 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 8

REST = 具象状态转移

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

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

特征：

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

无状态的优点：

1. Web 服务可以单独处理每个方法调用。
2. Web 服务不需要维护客户端之前的交互。
3. 这反过来又简化了应用程序设计。
4. HTTP 本身是一种与 TCP 不同的无状态协议，因此 RESTful Web 服务可以与 HTTP 协议无缝协作。

无国籍的缺点：

1. 需要向每个请求添加一个以标题形式显示的额外层，以保留客户端的状态。
2. 为了安全起见，我们需要为每个请求添加一个标头信息。

REST 支持的 HTTP 方法：

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

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

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

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

头：

HEAD 方法与 GET 相同，除了服务器不得在响应中返回消息正文。响应 HEAD 请求的 HTTP 头中包含的元信息应该与响应 GET 请求发送的信息相同。

选项：

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

HTTP 响应

去这里查看所有回复。

这里有几个重要的： 200 - OK 3XX - 需要从客户端和 url 重定向获取额外信息 400 - 错误请求
401 - 未授权访问
403 - 禁止
请求有效，但服务器拒绝操作。用户可能没有资源的必要权限，或者可能需要某种帐户。

404 - Not Found
无法找到请求的资源，但将来可能可用。客户的后续请求是允许的。

405 - Method Not Allowed 请求的资源不支持请求方法；例如，需要通过 POST 呈现数据的表单上的 GET 请求，或只读资源上的 PUT 请求。

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

Answer 9

REST是一种接近大系统(如Web)设计的特定方式.

这是一套"规则"(或"约束").

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

Answer 10

从你不知道 HTTP 和 REST 的区别

所以 REST 架构和 HTTP 1.1 协议是相互独立的，但 HTTP 1.1 协议被构建为遵循 REST 原则和约束的理想协议。查看 HTTP 和 REST 之间关系的一种方法是，REST 是设计，而 HTTP 1.1 是该设计的实现。

Answer 11

HTTP 是一种通过网络传输消息的通信协议。SOAP 是一种交换基于 XML 的消息的协议，可以使用 HTTP 传输这些消息。Rest 是一种交换任何（XML 或 JSON）消息的协议，这些消息可以使用 HTTP 传输这些消息。

Answer 12

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 13

REST API 必须是超文本驱动的

\n

Roy Fielding 的博客中提供了一组检查您正在构建 HTTP API 还是 REST API 的方法：

\n

\n

API 设计者，在将您的创建调用 REST API 之前，请注意以下规则：

\n

\n
• REST API 不应依赖于任何单一通信协议，尽管其到给定协议的成功映射可能取决于元数据的可用性、方法的选择等。一般来说，任何使用 URI 进行标识的协议元素都必须允许用于该标识的任何 URI 方案。[这里的失败意味着识别与互动没有分离。]
\n
• 除了填写或修复标准协议未指定位的详细信息（例如 HTTP\xe2\x80\x99s PATCH 方法或 Link 标头字段）之外，REST API 不应包含对通信协议的任何更改。对于损坏的实现（例如那些愚蠢到相信 HTML 定义了 HTTP\xe2\x80\x99s 方法集的浏览器）的解决方法应该单独定义，或者至少在附录中定义，并期望该解决方法最终会过时。[此处的失败意味着资源接口是特定于对象的，而不是通用的。]
\n
• REST API 应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或者为现有标准媒体类型定义扩展关系名称和/或支持超文本的标记。任何描述对感兴趣的 URI 使用什么方法的努力都应该完全在媒体类型的处理规则范围内定义（并且在大多数情况下，已经由现有媒体类型定义）。[这里的失败意味着带外信息正在驱动交互而不是超文本。]
\n
• REST API 不得定义固定的资源名称或层次结构（客户端和服务器的明显耦合）。服务器必须能够自由地控制自己的命名空间。相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构建适当的 URI，例如在 HTML 表单和 URI 模板中完成的操作。[这里的失败意味着客户端由于带外信息而假设资源结构，例如特定于域的标准，这是面向数据的等价于 RPC\xe2\x80\x99s 功能耦合]。
\n
• REST API 永远不应具有对客户端重要的 \xe2\x80\x9ctyped\xe2\x80\x9d 资源。规范作者可以使用资源类型来描述接口背后的服务器实现，但这些类型必须与客户端无关且不可见。对客户端来说唯一重要的类型是当前的表示\xe2\x80\x99s 媒体类型和标准化关系名称。[同上]
\n
• 输入 REST API 时，除了初始 URI（书签）和适合目标受众的标准化媒体类型集（即，期望任何可能使用该 API 的客户端能够理解）之外，无需任何先验知识。从那时起，所有应用程序状态转换必须由客户端对服务器提供的选择的选择驱动，这些选择存在于接收到的表示中或由用户\xe2\x80\x99s 对这些表示的操作暗示。转换可以由客户端对媒体类型和资源通信机制的了解来确定（或限制），这两者都可以在运行中（例如，按需编码）进行改进。[这里的失败意味着带外信息正在驱动交互而不是超文本。]
\n

\n

\n