HTTP 和 REST 有什么区别？

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

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

例如，REST 规定使用 DELETE 来擦除 URI 后面的文档（无论是文件、状态等），而使用 HTTP，您会误用 GET 或 POST 查询，例如 {4 }。

---

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

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

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

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

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

REST 架构提出的另一种限制是在与客户端（无状态）通信时不使用会话上下文，这意味着了解谁是客户端以及他想要什么所需的所有信息都与 Web 消息一起传递。对函数的每次调用都是自描述的，没有可以在消息中引用的与客户端的先前对话。因此，客户无法告诉您“给我下一页”，因为您没有会话来存储上一页是什么以及您想要什么样的页面，客户必须说“我的名字是 Yuval，给我一个特定论坛中特定帖子的第 2 页”。这意味着必须在通信中传输更多数据，但请考虑从“获取我的下一页”功能报告的错误与“获取堆栈溢出中问题 ID 2190836 的第 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 是一种契约，一种通信协议，而 REST 是一种概念，一种架构风格，可以使用 HTTP、FTP 或其他通信协议，但广泛用于 HTTP。

REST 意味着一系列关于服务器和客户端应该如何交互的约束。 HTTP 是一种具有给定服务器-客户端数据传输机制的通信协议，它最常用于 REST API 只是因为 REST 受到 WWW（万维网）的启发，在定义 REST 之前主要使用 HTTP，因此更容易实现 REST带有 HTTP 的 API 样式。

REST 中存在三个主要限制（但还有更多限制）：

服务器和客户端之间的交互只能通过超文本来描述。服务器和客户端应该是松耦合的，并且不对彼此做任何假设。客户端应该只知道资源入口点。交互数据应由服务器在响应中提供。服务器不应存储有关请求上下文的任何信息。请求必须是独立且幂等的（意味着如果无限重复相同的请求，则检索到完全相同的结果）

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

有关更多信息，请查看以下链接：

https://martinfowler.com/articles/richardsonMaturityModel.html

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

---

不完全的...

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

REST 最初是在 HTTP 的上下文中描述的，但不限于该协议。如果 RESTful 架构已经基于有意义的表示状态的传输为应用程序提供了丰富且统一的词汇表，则它们可以基于其他应用层协议。 RESTful 应用程序最大限度地利用预先存在的、定义明确的接口和所选网络协议提供的其他内置功能，并最大限度地减少在其之上添加新的应用程序特定功能。

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

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

---

REST = 表征状态转移

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

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

特征：

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

无国籍的优点：

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

无国籍的缺点：

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

REST 支持的 HTTP 方法：

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

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

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

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

头：

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

选项：

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

HTTP 响应

Go here for all the responses。

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

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

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

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

---

REST 是一种处理大型系统（如 Web）设计的特定方式。

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

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

---

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

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

---

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

---

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

---

REST API 必须是超文本驱动的

Roy Fielding's blog 提供了一组方法来检查您是在构建 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 永远不应该有对客户端很重要的“类型化”资源。规范作者可以使用资源类型来描述接口背后的服务器实现，但这些类型必须与客户端无关且不可见。对客户端重要的唯一类型是当前表示的媒体类型和标准化关系名称。 [同上] 除了初始 URI（书签）和适合目标受众的标准化媒体类型集（即，任何可能使用 API 的客户端都可以理解）之外，应该在没有先验知识的情况下输入 REST API。从那时起，所有应用程序状态转换必须由客户端选择服务器提供的选项驱动，这些选项出现在接收到的表示中或用户对这些表示的操作暗示。转换可以由客户端对媒体类型和资源通信机制的了解来确定（或限制），这两者都可以在运行中（例如，按需编码）得到改进。 [这里的失败意味着带外信息正在推动交互而不是超文本。]

---