REST和HTTP协议有什么区别？

Question

REST和HTTP协议有什么区别？

httprestterminology

38

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

- Adham

5个回答

36

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 GET操作。如果您想删除该客户，则只需使用相同URL的HTTP DELETE操作。

以下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

- bdoughan

1

REST中最重要的部分之一是使用超媒体以及它如何决定客户端状态。您的示例未显示此内容。 - Darrel Miller

它也有点反向，因为HTTP是一种利用REST风格的协议，而不是REST利用HTTP（尽管公平地说，一个RESTful webservice又会利用HTTP的RESTful质量）。 - Jon Hanna

14

REST不是一个协议，而是一种用于描述无状态、缓存客户端-服务器分布式媒体平台的通用架构。REST架构可以使用许多不同的通信协议实现，但HTTP远远是最常见的。

- aroth

5

REST不是一种协议，而是一种通过HTTP方式暴露应用程序的方法。

例如，您想要公开应用程序的一个名为“getClientById”的API。
不需要创建URL：

yourapi.com/getClientById?id=4
您可以这样做：
yourapi.com/clients/id/4

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

您可以利用HTTP方法：GET/DELETE/PUT
如果您发送的是Delete方法而不是GET，则yourapi.com/clients/id/4也可以处理删除操作，这意味着您想要删除该记录。

- fatnjazzy

5

由于URI是不透明的，在REST术语中，yourapi.com/getClientById?id=4和yourapi.com/clients/id/4之间没有区别。尽管在前面的URI中加入“get”动词可能会让人误解GETing可以做其他事情，但/clientById?id=4与第二种情况同样具有RESTful属性。 - Jon Hanna

或者说，如果引用实体指定的是/sadfhjsadfk/asfd/afsd/fsadfas作为客户端的URI，那么也可以使用它。但是，通过GET XForm、HTML表单或其他在文档本身中详细说明URI构造的机制可以获取/sadfhjsadfk/asfd/afsd?fsadfas=4（因此被视为超媒体，而不是基于URI格式的先验知识构造）。 - Jon Hanna

2

所有答案都是好的。

我在此添加了一个关于REST及其如何使用HTTP的详细说明。

REST = 表现层状态转移

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

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

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

无状态的优点：

Web服务可以单独处理每个方法调用。
Web服务不需要维护客户端的先前交互。
这进而简化了应用程序设计。
HTTP本身是一种无状态协议，与TCP完美配合，因此RESTful Web服务可以与HTTP协议无缝工作。

无状态的缺点：

需要在每个请求中添加一个额外的标题层以保留客户端的状态。
出于安全考虑，我们可能需要向每个请求添加标头信息。

REST支持的HTTP方法：

GET：/string/someotherstring：
它是幂等的（即多次调用应该每次返回相同的结果），理想情况下每次调用都应该返回相同的结果

PUT：
与GET相同。幂等并用于更新资源。

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

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

HEAD:

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

OPTIONS:

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

HTTP响应

点击此处获取所有响应。

以下是一些重要的响应：
200 - OK
3XX - 需要从客户端获取更多信息和URL重定向
400 - 请求无效
401 - 未经授权访问
403 - 禁止访问
请求是有效的，但服务器拒绝执行操作。用户可能没有某种资源的必要权限，或者可能需要某种类型的帐户。

404 - 未找到资源
所请求的资源无法找到，但可能在未来可用。客户端可以进行后续请求。

405 - 不允许使用该方法
不支持请求方法所请求的资源；例如，在需要通过POST提交数据的表单上发出GET请求，或者在只读资源上发出PUT请求。

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

- Pritam Banerjee

REST不是一种协议，也不仅限于XML和JSON。你所描述的大部分内容都是HTTP，而不是REST。 - user207421

@EJP 是的。让我修改那一行。 - Pritam Banerjee

您提供的大部分信息（以及更多）已经包含在文档中，因此我不确定这个答案是否真正增加了新的价值。 - Roman Vottner

@RomanVottner 这里提供的所有答案都包含文档中相同的信息，但仍然有这些答案。这些答案只涉及相关信息的表示。 - Pritam Banerjee

如果其他答案已经包含了你的答案中的信息，那么为什么需要你的答案呢？而且你的答案也不完全正确，因为它仍然声称REST是一种协议，但实际上它并不是（正如其他答案已经指出的那样）。此外，你不是只为了获得一定的约束集而应用REST，其主要目的是将客户端与服务器解耦，从而更加强大地应对变化。 - Roman Vottner

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jon Hanna · Accepted Answer

REST是一种协议的设计风格，由Roy Fielding在他的博士论文中开发并规范化了HTTP/1.0背后的方法，并找到了其良好的工作方式，然后使用这种更加结构化的理解来影响HTTP/1.1的设计。因此，虽然在很多方面都是事后的，但REST是HTTP背后的设计风格。

Fielding的论文可以在http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm找到，非常值得阅读，也非常易懂。博士论文可能会比较难懂，但是这篇论文非常清晰地描述了REST，即使我们没有类似的计算机科学水平，也能够轻松阅读。它有助于REST本身相当简单；它是那些在其他人想出之后变得显而易见的东西之一。（它还将许多老的Web开发人员自己辛苦学习的内容封装在一个简单的风格中，这使得许多人阅读它成为一个重要的“啊哈！”时刻）。

除了HTTP之外，其他应用级协议也可以使用REST，但HTTP是经典示例。

由于HTTP使用REST，所有使用HTTP的用例都是使用REST系统。Web应用程序或服务被描述为RESTful或非RESTful取决于它是否利用REST或反对它。

RESTful系统的经典示例是“普通”网站而没有cookies（cookies不总是反对REST，但它们可能会反对）：客户端状态通过用户单击链接来更改，这会加载另一个页面，或者进行GET表单查询以获得结果。 POST表单查询可以同时更改服务器和客户端状态（服务器根据POST执行某些操作，然后发送描述新状态的超文本文档）。 URIs描述资源，但是根据用户首选的内容类型或语言，描述其的实体（文档）可能会有所不同。最后，浏览器始终可以通过PUT和DELETE更新页面本身，尽管这从来不是很常见，如果有什么变化，现在也更少了。

使用HTTP的非RESTful系统的经典示例是将HTTP视为传输协议，并且每个请求都向相同的URI发送数据的POST，然后以类似RPC的方式处理它，可能具有共享状态的连接本身。

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

其主要优点是：可扩展性：缺乏共享状态使系统更具可扩展性（当我从一个高流量网站中删除所有会话状态的使用时，这一点非常明显。尽管我只是期望它能提供额外的性能，但像我这样长期反对会话的人也因为删除了一些几乎没有使用到会话的东西而受益匪浅。其实这甚至不是我一开始要做的事情！）

简单性：REST方式比较RPC模式更加简单，其中只有少数“动词”是可能的，每个资源类型可以在合理隔离的情况下进行推理。

轻量级实体：更像RPC模式的模型往往会在双向发送的实体中包含大量数据以反映RPC模式。这是不必要的。实际上，在某些情况下，只需要一个简单的纯文本文档，REST就足以发送（虽然这只是最终结果的情况，因为纯文本不能链接到相关资源）。另一个经典的例子是请求获取图像文件，RPC模式通常必须将其包装在另一种格式中，并且可能需要以某种方式进行编码以使其适合父格式（例如，如果RPC模式使用XML，则需要将图像base-64编码或类似编码以适应有效的XML）。RESTful模型将只传输与浏览器相同的文件。

可读性强的结果：并非总是如此，但通常可以轻松构建一个RESTful webservice，其中结果相对容易阅读，这有助于调试和开发。我甚至建立了一个XSLT，使整个东西可以被人类用作（相对粗糙的）网站，尽管它并不是主要用于人类使用（本质上，XSLT用作客户端呈现其给用户，它甚至不在规范中，只是为了让我自己的开发更容易！）。

服务器和客户端之间的绑定较松散：有利于后续开发或系统托管方式的变化。事实上，如果您坚持超文本模型，可以完全更改结构，包括从单个主机移动到不同服务的多个主机，而无需更改客户端代码。

缓存：对于客户端获取有关资源状态的GET操作，标准HTTP缓存机制允许声明资源在最早的某个日期之前不会意义改变（根本不需要查询），或者自上次查询以来没有改变（发送几百字节的头部即可说明这一点，而不是数千字节的数据）。性能的提高可以是巨大的（在某些情况下足以将某些东西的性能从不实用移动到不再关注性能的点）。

工具包的可用性：由于RESTful系统在相对简单的级别上运行，如果您拥有一个Web服务器，就可以构建RESTful系统的服务器，如果您有任何类型的HTTP客户端API（浏览器JavaScript中的XHR，.NET中的HttpWebRequest等），则可以构建RESTful系统的客户端。

弹性：特别是缺乏共享状态意味着客户端可以死亡并重新使用而服务器不知道，甚至服务器也可以死亡并重新使用而客户端不知道。显然，在此期间的通信将失败，但一旦服务器恢复在线，事情就可以像以前一样继续进行。这实际上还简化了用于冗余和性能的Web农场的使用-每个服务器都像它是唯一的服务器一样运作，并且事实上只处理给定客户端的一小部分请求也无关紧要。