在阅读了大量有关REST与SOAP之间差异的内容后,我得出了REST只是HTTP的另一种说法的印象。有人可以解释下REST为HTTP添加了哪些功能吗?
注意:我不需要比较REST和SOAP。
在阅读了大量有关REST与SOAP之间差异的内容后,我得出了REST只是HTTP的另一种说法的印象。有人可以解释下REST为HTTP添加了哪些功能吗?
注意:我不需要比较REST和SOAP。
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的博客这里提供了一些检查你是否正在构建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永远不应该有对客户端有意义的“类型化”资源。规范作者可以使用资源类型来描述接口背后的服务器实现,但是这些类型必须对客户端无关紧要且不可见。对客户端有意义的唯一类型是当前表示的媒体类型和标准化关系名称。[同上] - 进入REST API时,除了初始URI(书签)和适用于预期受众的标准化媒体类型集之外,不应具有任何先前的知识(即预计任何可能使用API的客户端都应理解)。从那时起,所有应用程序状态转换必须由客户端选择接收到的表示中存在或用户对这些表示的操作所暗示的服务器提供的选择来驱动。这些转换可以由客户端的媒体类型和资源通信机制的知识决定(或受限于),这两者都可以实时改进(例如,代码按需)。[这里的失败意味着带外信息驱动交互而不是超文本。]REST是SOAP的轻量级版本,没有添加糖或色素剂。
SOAP和REST的目标都是允许不同语言编写和使用不同通信协议的信息系统之间进行通信。
虽然SOAP使用API合同来公开其服务并定义客户端如何调用服务,应发送哪些参数以及应期望什么结果,但另一方面,REST不使用API合同。为了知道存在哪些服务以及如何调用它们,客户端应查看Rest API文档(可以在OpenAPI或Swagger中使用yml文件定义)。
其次,SOAP冗长,依赖于XML发送请求并描述服务、参数和返回的结果。另一方面,REST依赖于简单的JSON对象来发送请求和接收结果。JSON易于理解,轻巧,并且在发送请求或接收结果时不会使用太多带宽。