一、POST大一统时代

在微服务未火的年代，传统​​web​​​应用基本都是​​POST​​​和​​GET​​​定义接口，接口协议可能​​SOAP​​​和​​Http1​​​，数据类型是​​xml​​​或者​​json​​​，笔者属于中途改行，没有机会经历​​web​​​的发展史，但是维护过、对接过、重构过这些老系统，​​POST​​​可以基本满足所有接口的需要，且​​POST​​​开发简单，对于请求的拦截、日志等处理不需要额外的开发工作量，在当时跨域方案有​​Jsonp​​​、​​iframe​​​和​​proxy​​​反向代理，现在流行的​​CORS​​​则需要​​OPTIONS​​预检请求

简单来说，​​POST​​​能满足接口的需要，但是对于接口方法的分类则在​​path​​中做区分

二、RESTful微服务网红

​​SOA​​​向微服务过渡，就像​​EJB​​​被​​Spring​​取代一样，人人对于微服务这个新事物跃跃欲试

SOA

微服务

服务间通信

智能管道，例如：Enterprise Service Bus（ESB），往往采用重量级协议，例如SOAP或其他WS*标准

使用哑管道，例如消息代理，或者服务者之间点对点通信，使用例如REST或gRPC类的轻量级协议

数据管理

全局数据模型并共享数据库

每个服务都有自己的数据模型和数据库

典型服务规模

较大的单体应用

较小的服务

微服务往往基于轻量级的通信协议，服务粒度更小，​​RESTful​​​和​​DDD​​刚好契合微服务，也将这些架构设计理念发展起来

RESTful前世今生

Fielding是一个非常重要的人，他是​​HTTP​​​协议（1.0版和1.1版）的主要设计者、​​Apache​​​服务器软件的作者之一、​​Apache​​​基金会的第一任主席。Fielding将他对互联网软件的架构原则，定名为​​ REST​​​，即 ​​Representational State Transfer​​ 的缩写。

如果一个架构符合 ​​REST​​​ 原则，就称它为​​RESTful​​架构。

RESTful API Design 名词定义

Resource

有一些属性或者一些子资源，子资源可以是 一个简单的资源或者一组资源例如：​​book​​​, ​​user​​:

一组同类的资源对象，例如：​​books​​​, ​​users​​

HTTP Verbs

​​GET​​​（​​SELECT​​）：从服务器取出资源（一项或多项）。

​​POST​​​（​​CREATE​​）：在服务器新建一个资源。

​​PUT​​​（​​UPDATE​​）：在服务器更新完整的资源（客户端提供改变后的完整资源）。

​​DELETE​​​（​​DELETE​​）：从服务器删除资源。

Restful缺点

  1. GET请求无法满足多参数场景，URL长度有限制
  2. GET请求会被缓存，造成不可预料的错误
  3. GET请求参数常常存在有状态的保存操作，比如埋点
  4. GET请求数据安全性无法保证
  5. 在日志收集和分析时，聚合时需要解析path
  6. DELETE、PUT请求可能部分设备不兼容
  7. 简单PUT的path无法满足复杂业务需要，需要在Body里传入Action
  8. queryString和action在AOP切面处理麻烦
  9. 新的graphl和grpc破坏了Restful规范