HTTP和REST有什么区别？

13 回答

• 168

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

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

  例如，REST规定使用 DELETE 来删除URI后面的文档（无论是文件，状态等），而使用HTTP，您会滥用 GET 或 POST 查询，如 ...product/?delete_id=22 .

  回复于 2024-04-27T15:00:43+08:00
• 12

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

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

  回复于 2024-04-27T15:00:43+08:00
• 7

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

  REST意味着您在设计应用程序时使用的主要概念是资源：对于您要执行的每个操作，您需要定义通常只执行CRUD操作的资源，这是一项简单的任务 . 为此，使用HTTP协议中使用的4个动词对4个CRUD操作非常方便（Get for Read，POST用于CREATE，PUT用于UPDATE，DELETE用于DELETE） . 这与RPC（远程过程调用）的旧概念不同，在旧概念中，您有一组您希望由于用户的调用而执行的操作 . 如果您考虑如何在帖子上描述Facebook，使用RPC，您可以创建名为AddLikeToPost和RemoveLikeFromPost的服务，并管理它以及与FB帖子相关的所有其他服务，因此您不需要创建特殊的喜欢的对象 . 使用REST，您将拥有一个Like对象，该对象将使用Delete和Create功能单独管理 . 它还意味着它将描述数据库中的单独实体 . 这可能看起来像一个小的差异，但这样的工作通常会产生更简单的代码和更简单的应用程序 . 使用该设计，大多数应用程序的逻辑从对象的结构（模型）中显而易见，与RPC通常必须明确添加更多逻辑不同 .

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

  存在的另一个限制REST体系结构是在与客户端（无状态）通信时不使用会话上下文，这意味着所有信息需要了解谁是客户端以及他想要的内容与Web消息一起传递 . 对函数的每次调用都是自描述的，之前没有与客户端的对话，可以在消息中引用 . 因此，客户端无法告诉您“给我下一页”，因为您没有会话来存储上一页和您想要的页面类型，客户端必须说“我的名字是yuval，get我在特定论坛的特定帖子的第2页“ . 这意味着在通信中需要传输更多的数据，但是想一想在查找“让我下一页”功能报告的错误与“让我在堆栈溢出中找到问题ID 2190836的第2页”之间的区别 .

  当然还有很多东西，但我认为这是茶匙中的主要概念 .

  回复于 2024-04-27T15:00:43+08:00
• 1

  REST不向HTTP添加任何特定功能，但它是与HTTP一起开发的架构风格，并且最常使用HTTP作为其应用层协议 .

  回复于 2024-04-27T15:00:43+08:00
• 62

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

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

  自描述约束要求RESTful请求在用户意图中完全自我描述 . 这允许中间人（代理和缓存）安全地对消息采取行动 .

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

  回复于 2024-04-27T15:00:43+08:00
• 9

  不完全的...

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

  回复于 2024-04-27T15:00:43+08:00
• 3

  据我了解，REST强制使用可用的HTTP命令，因为它们是用来实现的 .

  例如，我可以这样做：

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

  但是休息时我会使用“DELETE”请求方法，不需要“方法”查询参数

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

  回复于 2024-04-27T15:00:43+08:00
• 1

  REST是一种接近大系统（如Web）设计的特定方式 .

  这是一套“规则”（或“约束”） .

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

  回复于 2024-04-27T15:00:43+08:00
• 0

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

  回复于 2024-04-27T15:00:43+08:00
• 3

  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
  

  回复于 2024-04-27T15:00:43+08:00
• 23

  REST =具象国家转移

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

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

  Features:

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

  Advantages of Statelessness:

  • Web服务可以单独处理每个方法调用 .

  • Web服务无需维护客户端之前的交互 .

  • 这反过来简化了应用程序设计 .

  • HTTP本身就是一种与TCP不同的无状态协议，因此RESTful Web服务可以与HTTP协议无缝协作 .

  Disadvantages of Statelessness:

  • Headers 形式的一个额外层需要添加到每个请求以保留客户端的状态 .

  • 为了安全起见，我们需要为每个请求添加标头信息 .

  HTTP Methods supported by REST:

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

  PUT：和GET一样 . 幂等并用于更新资源 .

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

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

  头：

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

  选项：

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

  HTTP Responses

  Go here for all the responses .

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

  404 - 未找到
  找不到请求的资源，但将来可能会提供 . 客户的后续请求是允许的 .

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

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

  回复于 2024-04-27T15:00:43+08:00
• 47

  REST APIs must be hypertext-driven

  从Roy Fielding's blog这里's a set of ways to check if you'重新构建HTTP API或REST API：

  API设计人员在调用创建REST API之前请注意以下规则：REST API不应依赖于任何单一通信协议，尽管其成功映射到给定协议可能取决于元数据的可用性，方法的选择通常，任何使用URI进行标识的协议元素都必须允许任何URI方案用于该标识 . [此处的失败意味着标识不会与交互分离 . ] REST API不应包含对通信协议的任何更改，除了填写或修复标准协议的未指定位的详细信息，例如HTTP的PATCH方法或链接头字段 . 破解实现的解决方法（例如那些足以让人相信HTML定义HTTP方法集的浏览器）应该单独定义，或者至少在附录中定义，期望解决方法最终会过时 . [这里的失败意味着资源接口是特定于对象的，而不是通用的 . ] REST API应该花费几乎所有的描述性工作来定义用于表示资源和驱动应用程序状态的媒体类型，或者定义扩展关系现有标准媒体类型的名称和/或超文本标记 . 在媒体类型的处理规则的范围内（并且在大多数情况下，已经由现有媒体类型定义）应该完全定义用于描述在感兴趣的URI上使用什么方法的任何努力 . [失败在这里意味着带外信息驱动交互而不是超文本 . ] REST API不能定义固定资源名称或层次结构（客户端和服务器的明显耦合） . 服务器必须能够自由控制自己的命名空间 . 相反，允许服务器通过在媒体类型和链接关系中定义这些指令来指示客户端如何构造适当的URI，例如在HTML表单和URI模板中完成的 . [这里的失败意味着客户端由于带外信息而假设资源结构，例如特定于域的标准，这是面向数据的，与RPC的功能耦合相当] . REST API永远不应具有对客户端有意义的“类型化”资源 . 规范作者可以使用资源类型来描述接口后面的服务器实现，但这些类型必须与客户端无关且不可见 . 对客户来说重要的唯一类型是当前表示的媒体类型和标准化的关系名称 . [同上]应输入REST API，除了初始URI（书签）和适用于目标受众的标准化媒体类型集之外没有任何先验知识（即，任何可能使用API的客户都应该理解） . 从那时起，所有应用程序状态转换必须由客户端选择服务器提供的选择来驱动，这些选择存在于接收的表示中或者由用户对这些表示的操纵所暗示 . 转换可以由客户端对媒体类型和资源通信机制的知识来确定（或限制），这两者都可以在运行中（例如，按需代码）进行改进 . [失败在这里意味着带外信息是推动互动而不是超文本 . ]

  回复于 2024-04-27T15:00:43+08:00
• 0

  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之前 REST was inspired by WWW (world wide web) which largely used HTTP ，因此使用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-hypertext-driven

  回复于 2024-04-27T15:00:43+08:00