初见微服务之RESTful API

1. REST名称由来

    REST全称为Representational State Transfer，即表述性状态转移，最先由Roy Feilding博士在世纪之交（2000年）提出，喜欢追根溯源的朋友能够读一下他的博士论文《Architectural Styles and the Design of Network-based Software Architectures》，这时距HTTP1.1协议标准正式发布（1999年6月）仅一年的时间。

    岁月的痕迹跨越了十多年，技术的进步突飞猛进，全部的人都在谈论着应用容器化、服务解耦、DevOps开发运维文化等等。咱们变得喜新厌旧，技术成了快餐，框架是愈来愈多的舶来品。此时，咱们是否应该静一静，看看技术的起源，想一想咱们如何成为软件的设计师，而不是代码的奴隶、资本的工具？REST做为历史的宝藏，被愈来愈多的人挖掘、概括、推陈出新，近几年占领了几乎全部的大型互联网公司的开放API，国外如google（https://developers.google.com/apis-explorer）、facebook，国内的有豆瓣、腾讯的公众平台等。

    在这里，我要替SOAP说几句话，技术的进步始终是从无到有，由繁入简的。在必定的时间里SOAP知足了web服务的设计要求，达到了对外提供服务的目的，尽管十分的（协议）晦涩、（解析）生硬。企业级的软件依然有不少保留着SOAP式的服务，我工做过程当中对接的一些政府如卫生计划委员会、医疗HIS系统其实依然是保有SOAP的，它活在计算机构建的这一社会的血液里、空气里。

2. 什么是REST？

    须要注意的是REST并非一个标准或者协议，而是一种设计风格，或者说是一个设计web服务的最佳实践，其要点以下：

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

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

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

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

    非RESTful的设计示意图以下：

   

    RESTful的设计示意图以下：

   

3. REST设计

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

   

    我工做过程当中的一些最佳实践是：

    1) 对option的选择不该过多，不该死板教条，经常使用的有GET、POST便可；

    2) URI的设计应已名词为主、动词为辅，层次清晰；

    3) 参数的设计应已单词为主，少用多个词的驼峰链接形式；

    4) 功能与URI或者参数设计冲突时，应以功能实现为主。

4. REST的劣势

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

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

    c. HTTP option使用不当；

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

    ……

5. 微服务为何选择REST？

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

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

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