HTTP和REST有什么区别？

在阅读了很多关于REST和SOAP之间的区别之后，我得到了REST只是HTTP的另一个说法的印象。有人可以解释一下REST添加到HTTP的功能吗？

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

更新：感谢您的回答。现在对我来说很清楚，REST只是关于如何使用HTTP的一组规则。因此，我发布了有关这些约定的优点的后续报告。

注意：我现在掌握了REST的含义；正如Emil Ivanov所说，REST意味着按照原意使用HTTP。但是，我不确定这是否值得单独使用，我当然也不会对此大肆宣传。

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

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

例如，REST规定了DELETE擦除URI后面的文档（文件，状态等）的用法，而使用HTTP时，您会误用GET或POST查询，例如...product/?delete_id=22。

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

REST意味着设计应用程序时使用的主要概念是资源：对于要执行的每个动作，您需要定义一个资源，通常只对它执行CRUD操作，这是一个简单的任务。为此，使用HTTP协议中的4个动词来针对4个CRUD操作非常方便（Get for Read，POST用于CREATE，PUT用于UPDATE和DELETE用于DELETE）。这与RPC（远程过程调用）的较早概念不同，在RPC中，您有一些要根据用户调用执行的操作。例如，如果您考虑如何像在帖子上那样描述Facebook，则可以使用RPC创建名为AddLikeToPost和RemoveLikeFromPost的服务，并将其与与FB帖子相关的所有其他服务一起进行管理，因此您无需创建特殊的赞的对象。使用REST，您将有一个Like对象，该对象将通过Delete和Create函数进行单独管理。这也意味着它将在您的数据库中描述一个单独的实体。看起来似乎没有什么区别，但是那样工作通常会产生简单得多的代码和简单得多的应用程序。通过这种设计，大多数应用程序的逻辑从对象的结构（模型）中是显而易见的，与通常需要显式添加更多逻辑的RPC不同。

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

当前存在的另一种限制REST体系结构是在与客户端通信时（无状态）不使用会话上下文，这意味着所有信息都需要了解谁是客户端，以及他想要的信息与Web消息一起传递。每个对函数的调用都是自描述性的，消息中没有引用与客户端的先前对话。因此，客户无法告诉您“下一页给我”，因为您没有用于存储上一页和所需页面的会话，因此客户必须说“我叫尤瓦尔，我在特定论坛中特定帖子的第2页”。这意味着必须在通讯中传输更多的数据，但请考虑一下查找“获取下一页”功能报告的错误与反对“

当然，还有很多其他内容，但是我认为这是一茶匙的主要概念。

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

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

自我描述约束要求RESTful请求才能完全按照用户意图进行自我描述。这允许中介（代理和缓存）对消息进行安全操作。

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

据我了解，REST强制使用了将要使用的可用HTTP命令。

例如，我可以这样做：

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

但是休息一下，我将使用“ DELETE”请求方法，而无需使用“方法”查询参数

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

不完全的...

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

REST是一种用于设计大型系统（如Web）的特定方法。

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

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

REST =代表性状态转移

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

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

特征：

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

无国籍的优势：

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

无国籍的缺点：

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

REST支持的HTTP方法：

GET：/ string / someotherstring这是幂等的，理想情况下每次拨打电话时应返回相同的结果

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

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

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

头：

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

选项：

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

HTTP响应

去这里获得所有答复。

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

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

405-不允许使用的方法请求的资源不支持请求方法。例如，要求通过POST呈现数据的表单上的GET请求，或只读资源上的PUT请求。

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

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

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-超文本驱动

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

From 您不知道HTTP和REST之间的区别

因此REST体系结构和HTTP 1.1协议是相互独立的，但是HTTP 1.1协议是遵循REST原理和约束的理想协议。查看HTTP和REST之间关系的一种方法是REST是设计，而HTTP 1.1是该设计的实现。

REST API必须是超文本驱动的

在Roy Fielding的博客中，这是检查您正在构建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的任何客户端都希望理解）的一组标准化媒体类型之外，没有其他先验知识。从那时起，所有应用程序状态转换必须由客户端选择服务器提供的选择来驱动，这些选择出现在接收的表示中或由用户对这些表示的操纵来暗示。过渡可以由客户端对媒体类型和资源通信机制的了解来确定（或受其限制），这两者都可以动态地（例如，按需编码）进行改进。[此处的失败表示带外信息正在驱动交互，而不是超文本。]