Rest

Rest全称Representational State Transfer，即表述性状态转移，2000年提出，这时距HTTP1.1协议标准正式发布（1999年6月）仅一年的时间。

在一定的时间里SOAP满足了web服务的设计要求，达到了对外提供服务的目的，尽管协议十分晦涩，解析生硬。企业级的软件依然有很多保留着SOAP式的服务，一些*系统依然保留着SOAP

Rest并不是一个标准或协议，而是一种设计风格，或者说是一个设计web服务的最佳实践，主要内容：

1. 面向资源的URI设计，如user/register;
2. 对资源的操作包括增、删、改、查（和数据库层的操作极为相似）；
3. 连接具有无状态性，即每一次的响应只依赖于这一次的请求；
4. 利用HTTP协议实现以上的设计思想。

非Restful的设计：

Restful的设计：

Rest设计

REST的设计利用了HTTP协议的请求选项，如GET、POST、PUT、DELETE。设计的简单示意图如下：

工作中最佳实践：

1. 对选项的选择不应过多，不应死板教条，常用的有GET、POST即可；
2. URI的设计应已名词为主、动词为辅，层次清晰；
3. 参数的设计应已单词为主，少用多个词的驼峰连接形式；
4. 功能与URI或者参数设计冲突时，应以功能实现为主。

Rest劣势

1. 一千个读者，一千个哈姆雷特，在设计评审粗糙的情况下，面向资源的URI设计五花八门；
2. URI泛滥，版本管理困难；
3. HTTP 选项使用不当；
4. REST API 参数、返回值设计不当；

…

微服务为什么选择Restful API

微服务组件拆分、服务解耦，各服务组件间的调用需要通过接口实现，Rest可以让这些服务风格统一、便于维护和管理；

服务层次化的前提是组件的拆分，如用户组件url前缀需要以 /user 开头，配置系统的前缀需要以 /configuration 开头，用程序自动对前缀校验

Restful API 的入参、出参，均以Java Bean的形式体现，称之为接口协议。业务接口协议可以继承用户组件协议，各业务协议之间不可以不可以继承和聚合，这些规则的设定，冗余的思想达到解耦的目的