rest和微服务

REST并不是一个标准或者协议，而是一种设计风格。REST规范把所有内容都视为资源，网络上一切皆资源。

1) 面向资源的URI设计，如user/register;

2) 对资源的操作包括增、删、改、查（和数据库层的操作极为相似）；

3) 连接具有无状态性，即每一次的响应只依赖于这一次的请求；

4) 利用HTTP协议实现以上的设计思想。

rest使用 HTTP 协议处理数据通信。REST架构对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。

HTTP动词与REST风格CRUD对应关系：

HTTP规范，标准，通用，无论哪种语言都支持http协议。如果你是对外开放API，例如开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持的几个协议都包含RESTful。

REST调用及测试都很方便。

建议在多系统之间的内部调用采用RPC。对外提供的服务，Rest更加合适。

rest url设计

rest劣势

a. 一千个读者，一千个哈姆雷特，在设计评审粗糙的情况下，面向资源的URI设计五花八门；

b. URI泛滥，版本管理困难；

c. HTTP option使用不当；

d. REST API 参数、返回值设计不当；

微服务为什么使用rest

随着组件拆分、服务解耦，各组件之间的调用均是通过接口实现，REST可以让这些拆分后的服务风格统一、便于维护和管理，目前我所参与设计和开发的系统存在100+的服务接口，如果不统一风格、调用方式，想必将是一场灾难。服务层次化的前提是组件的拆分，如用户组件URI前缀需要以 /user 开头，配置系统的前缀需要以 /configuration开头，用程序自动对前缀校验。

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

当然微服务从来不是银弹，REST也不是救世主，这是一个发现问题、解决问题的过程，从来没有最完美的，只有最合适的。