当前位置: 首页>后端>正文

有那么多接口 rest接口有什么特点 rest接口协议

内容摘录自极客时间课程《趣谈网络协议》,


目录

  • 基于JSON的RESTful接口协议
  • 服务端无状态化
  • 服务发现
  • 小结
  • 参考

基于JSON的RESTful接口协议

RESTful是一种架构风格,全称Representational State Transfer(表述性状态转移),出自一篇论文《Architectural Styles and the Design of Network-based Software Architectures》。这篇文章从深层次,更加抽象地论证了一个互联网应用应该有的设计要点,而这些设计要点,成为后来我们能看到的所有高并发应用设计都必须要考虑的问题,再加上 REST API 比较简单直接,所以后来几乎成为互联网应用的标准接口。

和 SOAP 不一样,REST 不是一种严格规定的标准,它其实是一种设计风格。如果按这种风格进行设计,RESTful 接口和 SOAP 接口都能做到,只不过后面的架构是 REST 倡导的,而 SOAP 相对比较关注前面的接口。

服务端无状态化

服务端维护资源的状态,客户端维护会话的状态。对于服务端来讲,只有资源的状态改变了,客户端才调用 POST、PUT、DELETE 方法来找我;如果资源的状态没变,只是客户端的状态变了,就不用告诉我了,对于我来说都是统一的 GET。

按照这种思路,对于 API 的设计,就慢慢变成了以资源为核心,而非以过程为核心。也就是说,客户端只要告诉服务端你想让资源状态最终变成什么样就可以了,而不用告诉我过程,不用告诉我动作。

这种 API 的设计需要实现幂等,因为网络不稳定,就会经常出错,因而需要重试,但是一旦重试,就会存在幂等的问题,也就是同一个调用,多次调用的结果应该一样,不能一次支付调用,因为调用三次变成了支付三次。不能进入 cd a,做了三次,就变成了 cd a/a/a。也不能扣减库存,调用了三次,就扣减三次库存。

按照这种设计模式,无论 RESTful API 还是 SOAP API 都可以将架构实现成无状态的,面向资源的、幂等的、横向扩展的、可缓存的。

服务发现

对于RESTful API,使用基于http的传输协议和基于json的协议约定。最后使用Eureka实现注册中心,维护注册的服务列表。

服务分服务提供方,它向 Eureka 做服务注册、续约和下线等操作,注册的主要数据包括服务名、机器 IP、端口号、域名等等。另外一方是服务消费方,向 Eureka 获取服务提供方的注册信息。为了实现负载均衡和容错,服务提供方可以注册多个。

小结

  1. SOAP 过于复杂,而且设计是面向动作的,因而往往因为架构问题导致并发量上不去。
  2. RESTful 不仅仅是一个 API,而且是一种架构模式,主要面向资源,提供无状态服务,有利于横向扩展应对高并发。

参考

趣谈网络协议-基于JSON的RESTful接口协议



https://www.xamrdz.com/backend/3nu1960026.html

相关文章: