REST 和 HTTP 协议有什么区别？

Question

什么是 REST 协议，它与 HTTP 协议有什么不同？

Answer 1

REST 是一种协议设计风格，它是由 Roy Fielding 在他的博士论文中开发的，并形式化了 HTTP/1.0 背后的方法，找到了适合它的方法，然后利用对它的这种更结构化的理解来影响设计HTTP/1.1 的。因此，虽然它在很多方面都是事后诸葛亮，但 REST 是 HTTP 背后的设计风格。

菲尔丁的论文可以在http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm 找到，非常值得一读，也非常易读。博士论文可能非常难读，但这篇文章描述得非常好，对于我们这些没有同等计算机科学水平的人来说非常易读。 REST 本身非常简单，这很有帮助；这是其他人提出后显而易见的事情之一。 （就此而言，它还以一种简单的风格封装了许多老 Web 开发人员通过艰苦的方式自己学到的东西，这使得阅读它成为许多人的主要“哈哈！”时刻）。

其他应用层协议以及 HTTP 也可以使用 REST，但 HTTP 是典型的例子。

因为 HTTP 使用 REST，所以所有 HTTP 的使用都是使用 REST 系统。将 Web 应用程序或服务描述为 RESTful 或非 RESTful 关系到它是利用 REST 还是与之对抗。

RESTful 系统的经典示例是一个没有 cookie 的“普通”网站（cookie 并不总是与 REST 相悖，但也可以）：客户端状态通过用户单击加载另一个页面的链接而改变，或者执行 GET 表单查询会带来结果。 POST 表单查询可以改变服务器和客户端的状态（服务器在 POST 的基础上做一些事情，然后发送一个描述新状态的超文本文档）。 URI 描述资源，但描述它的实体（文档）可能会根据用户首选的内容类型或语言而有所不同。最后，浏览器总是可以通过 PUT 和 DELETE 更新页面本身，尽管这从来都不是很常见，而且现在更不常见了。

使用 HTTP 的非 RESTful 系统的典型示例是将 HTTP 视为传输协议，并且每个请求都会将数据的 POST 发送到相同的 URI，然后在类似 RPC 的方式中对其进行操作方式，可能与连接本身具有共享状态。

一个 RESTful 计算机可读（即不是浏览器中的网站，而是以编程方式使用的东西）系统将通过 GETting URI 获取有关资源的信息，然后返回一个文档（例如 XML，但不一定），该文档将描述资源的状态，包括相关资源的 URI（因此是超媒体），通过 PUT 描述新状态或删除它们的实体来更改它们的状态，并通过 POST 执行其他操作。

主要优点是：

可扩展性：缺少共享状态使系统更具可扩展性（当我从一个受到严重打击的网站中删除所有会话状态的使用时，我得到了大规模的证明，而我希望它能够提供一些额外的性能，甚至像我这样的长期反会话倡导者被删除很少使用的会话所带来的巨大收益所震撼，这甚至不是我删除它们的原因！）

简单性：REST 比更多类似 RPC 的模型更简单的方式有多种，特别是只有少数“动词”是可能的，并且每种类型的资源都可以在合理的隔离中进行推理给其他人。

轻量级实体：更多类似 RPC 的模型往往会在实体中以两种方式发送大量数据，以反映类似 RPC 的模型。这不是必需的。确实，有时在给定的情况下真正需要一个简单的纯文本文档，在这种情况下，使用 REST，这就是我们需要发送的全部内容（尽管这只是一个“最终结果”的情况，因为纯文本 -文本不链接到相关资源）。另一个经典示例是获取图像文件的请求，类 RPC 模型通常必须将其包装为另一种格式，并且可能以某种方式对其进行编码以使其位于父格式中（例如，如果类 RPC 模型使用 XML ，图像将需要是 base-64'd 或类似的以适合有效的 XML）。一个 RESTful 模型只会像向浏览器一样传输文件。

人类可读的结果：不一定如此，但通常很容易构建结果相对容易阅读的 RESTful Web 服务，这有助于调试和开发无止境。我什至建立了一个 XSLT 意味着整个东西可以被人类用作（相对粗略的）网站，尽管它主要不是供人类使用的（本质上，XSLT 充当客户端来展示它）用户，它甚至不在规范中，只是为了让我自己的开发更容易！）。

服务器和客户端之间的绑定更松散：使以后的开发或系统托管方式更容易移动。事实上，如果你坚持超文本模型，你可以改变整个结构，包括从单一主机转移到不同服务的多台主机，而根本不需要改变客户端代码。

缓存：对于客户端获取资源状态信息的 GET 操作，标准 HTTP 缓存机制允许资源最早在某个日期之前不会有意义地更改的语句（无需查询直到那时），或者自上次查询以来它没有改变（发送几百字节的标题，而不是几千字节的数据）。性能的改进可能是巨大的（在某些情况下，大到足以将某些东西的性能从使用不切实际的地步转移到性能不再是问题的地步）。

工具包的可用性：因为它工作在一个相对简单的级别，如果你有一个网络服务器，你可以构建一个 RESTful 系统的服务器，如果你有任何类型的 HTTP 客户端 API（浏览器 javascript 中的 XHR，.NET 中的 HttpWebRequest 等） ) 你可以构建一个 RESTful 系统的客户端。

弹性：特别是缺少共享状态意味着客户端可以在服务器不知情的情况下死亡并重新使用，甚至服务器也可以在客户端不知情的情况下死亡并重新使用。显然，在此期间的通信将失败，但一旦服务器重新上线，事情就可以照常进行。这也真正简化了使用网络农场来实现冗余和性能 - 每台服务器就像它是唯一的服务器一样，它实际上只处理来自给定客户端的一小部分请求并不重要。

Answer 2

REST 是一种利用 HTTP 协议的方法，而不是它的替代方案。

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

数据由 URL 唯一引用，并且可以使用 HTTP 操作（GET、PUT、POST、DELETE 等）进行操作。消息/响应支持多种 MIME 类型，但最常见的是 XML 和 JSON。

例如，要读取有关客户的数据，您可以对 URL http://www.example.com/customers/1 使用 HTTP 获取操作。如果您想删除该客户，只需使用相同 URL 的 HTTP 删除操作即可。

下面的 Java 代码演示了如何通过 HTTP 协议进行 REST 调用：

String uri =
    "http://www.example.com/customers/1";
URL url = new URL(uri);
HttpURLConnection connection =
    (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/xml");

JAXBContext jc = JAXBContext.newInstance(Customer.class);
InputStream xml = connection.getInputStream();
Customer customer =
    (Customer) jc.createUnmarshaller().unmarshal(xml);

connection.disconnect();

有关 Java (JAX-RS) 示例，请参阅：

• http://bdoughan.blogspot.com/2010/08/creating-restful-web-service-part-45.html

Answer 3

REST 不是协议，它是用于描述无状态、缓存客户端-服务器分布式媒体平台的通用架构。 REST 架构可以使用多种不同的通信协议来实现，尽管 HTTP 是迄今为止最常见的。

Answer 4

REST 不是一种协议，它是一种公开应用程序的方式，主要通过 HTTP 完成。

例如，您想公开执行 getClientById 的应用程序的 api
而不是创建一个 URL

yourapi.com/getClientById?id=4
你可以做到
yourapi.com/clients/id/4

由于您使用的是 GET 方法，这意味着您要获取数据

您可以利用 HTTP 方法：GET/DELETE/PUT
yourapi.com/clients/id/4 也可以处理delete，如果你发送delete方法而不是GET，意味着你要dekete记录

Answer 5

所有答案都很好。

我在此添加对 REST 及其如何使用 HTTP 的详细说明。

REST = 表征状态转移

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

它是无状态的，这意味着理想情况下，客户端和服务器之间不应保持任何连接。

客户端负责将其上下文传递给服务器，然后服务器可以存储此上下文以处理客户端的进一步请求。例如，服务器维护的会话由客户端传递的会话标识符来标识。

无国籍的优势：

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

无国籍的缺点：

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

REST 支持的 HTTP 方法：

获取：/string/someotherstring:
它是幂等的（意味着多次调用每次都应该返回相同的结果）并且理想情况下每次调用都应该返回相同的结果

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

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

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

头：

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

选项：

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

HTTP 响应

Go here for all the responses。

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

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

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

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