HTTP和REST之间的区别是什么?

不太……

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的支持者 说它增加了不必要的东西 复杂性。< / p >

不，休息是HTTP应该是使用的方式。

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

例如，REST规定使用DELETE来删除URI后面的文档(可以是文件、状态等)，而使用HTTP，你会滥用GET或POST查询，如...product/?delete_id=22。

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

如果您正在寻找REST中区分RESTful应用程序与任何HTTP应用程序的最重要的约束，我会说“自描述”约束和超媒体约束(又名hypermedia as the Engine of application State (HATEOAS))是最重要的。

自描述约束要求RESTful请求在用户意图中是完全自描述的。这允许中介(代理和缓存)安全地对消息进行操作。

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

REST是一种设计大型系统(如web)的特殊方法。

它是一组“规则”(或“约束”)。

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

REST强制使用可用的HTTP命令，因为它们应该被使用。

例如，我可以这样做:

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

但在休息时，我会使用“删除”键。请求方法，不再需要“;method”;查询参数

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

HTTP是一种用于通信的协议，通常用于与互联网资源或web浏览器客户端的任何应用程序通信。

REST意味着您在设计应用程序时使用的主要概念是资源:对于您想要执行的每个操作，您需要定义一个资源，您通常只在该资源上执行CRUD操作，这是一个简单的任务。为此，使用HTTP协议中使用的四个动词来对抗四个CRUD操作非常方便(GET用于读取，POST用于创建，PUT用于更新，DELETE用于删除)。

这与RPC(远程过程调用)的旧概念不同，在RPC中，作为用户调用的结果，您有一组希望执行的操作。例如，如果你考虑如何在一个帖子上描述一个Facebook点赞，使用RPC你可以创建名为AddLikeToPost和RemoveLikeFromPost的服务，并管理它与所有其他与FB帖子相关的服务，因此你不需要为点赞创建特殊的对象。

使用REST，您将拥有一个Like对象，它将与Delete和Create函数分开管理。这也意味着它将在数据库中描述一个单独的实体。这看起来可能是一个很小的差异，但这样工作通常会产生更简单的代码和更简单的应用程序。通过这种设计，应用程序的大部分逻辑从对象的结构(模型)中是显而易见的，不像RPC，你通常必须显式地添加更多的逻辑。

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

REST体系结构提出的另一个限制是在与客户端通信时不使用会话上下文(无状态)，这意味着了解谁是客户端以及他想要什么所需的所有信息都随web消息传递。对函数的每次调用都是自描述的，没有与客户端之前的对话可以在消息中引用。因此，客户不能告诉你“给我下一页”。因为你没有一个会话来存储什么是前一页，什么类型的页面你想要，客户会说“我的名字是Yuval，让我在一个特定的论坛的特定帖子的第2页”。这意味着在通信中要传输更多的数据，但想想从“给我下一页”中发现bug的区别;与“让我得到问题ID 2190836的第2页堆栈溢出”相反的函数。

当然还有很多，但在我看来，这些是茶匙的主要概念。

休息不一定绑定到HTTP。基于rest的web服务只是遵循基于rest的体系结构的web服务。

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

具象状态传输

休息是一组规则，当遵循这些规则时，使您能够构建具有特定的理想约束集的分布式应用程序。

休息是一个交换任何(XML, JSON等)消息的协议，可以使用HTTP传输这些消息。

特点:

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

无国籍的好处:

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

无国籍的缺点:

1. 需要在每个请求中添加一个标题形式的额外层，以保存客户机的状态。
2. 为了安全起见，我们需要为每个请求添加一个头部信息。

REST支持的HTTP方法:

POST:应该包含url和正文 用于创建资源。理想情况下，多个调用应该返回不同的结果，并应该创建多个产品 < p >删除: 删除服务器上的资源。< / p >

负责人:

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

选项:

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

HTTP响应

点击这里查看所有的回答。

404 -未找到
无法找到所请求的资源，但将来可能可用。

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

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

REST api必须是超文本驱动的

从罗伊·菲尔丁的博客这里有一组方法来检查你是在构建HTTP API还是REST API:

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

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

HTTP是一种契约，一种通信协议，REST是一种概念，一种架构风格，可以使用HTTP、FTP或其他通信协议，但广泛与HTTP一起使用。

REST暗示了一系列关于服务器和客户端应该如何交互的约束。HTTP是一种具有特定机制的通信协议，用于服务器-客户端数据传输，它最常用于REST API，因为REST是受WWW (world wide web)的启发，在REST定义之前，WWW大量使用HTTP，因此使用HTTP更容易实现REST API风格。

REST中有三个主要的约束(但还有更多):

1. 服务器和客户端之间的交互应该只通过超文本来描述。
2. 服务器和客户端应该是松散耦合的，彼此之间不做任何假设。客户端应该只知道资源入口点。交互数据应该由服务器在响应中提供。
3. 服务器不应该存储任何关于请求上下文的信息。请求必须是独立的和幂等的(意思是如果相同的请求无限次重复，得到的结果完全相同)

HTTP只是一种通信协议(一种工具)，可以帮助实现这一点。

欲了解更多信息，请查看以下链接:

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

从你不知道HTTP和REST之间的区别

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