微服务架构下的API接口驱动开发，设计和集成( 三 ) 今天谈下在微服务架构下

而这个时候张三往往对整个前端功能实现和页面都不关心，仅仅关注自己逻辑实现和接口提供，关注自己的单元测试验证。而小敏负责前端，实际上小敏对整个功能的业务逻辑和场景往往也并不清楚，仅仅只能够测试数据的录入，查询装载等正常。
即这个时候张三和小敏都无法完整地进行前端功能页面的测试，这个时候导致很多测试工作都转到测试阶段后由测试人员才能够测试和发现。
这本身也就导致了功能实现问题的进一步朝后面泄露。
如何解决这个问题？
第一个方法就是负责后端的张三必须做完整的单元测试，而这个工作量极大，大部分开发人员实际都无法做完整的单元测试。第二个方法就是该工作还是由小敏负责，那么小敏就必须参与前期需求和接口评审，熟悉需求和业务场景，才能够展开。
规模不大的项目没必要前后端分离
这个也是我在前面强调过的要给观点，尽管前后端分离可以进一步实现微服务间的解耦，但是也增加了单个功能实现多个角色之间沟通的协同量。
项目规模再小，你还得找到要给后端角色或前端开发两个角色，或者你需要找到一个很厉害的都懂的全栈人员。而实际上前后端分离本身带来大量的集成工作量，同时后端分离的API接口本身并没有体现出应有的粗粒度和复用价值。
本来一个简单项目，前端用easyui就能搞定，结果用微服务和前后端分离后却越搞越复杂。
Http Rest API接口设计对于HTTP Rest接口的设计，网上已经有很多文章都有详细的阐述，今天再重新整理下这里面的一些重点，大家都清楚Rest接口是面向资源的接口设计方法，而且基于原生的Http协议，因此里面就有两个最关键的点，一个就是对资源的理解，一个就是对操作的理解。
文章插图
图片来源网络
什么是RESTful架构，重要的几点如下：

每一个URI代表一种资源；
客户端和服务器之间，传递这种资源的某种表现层；
客户端通过四个HTTP动词（GET/POST/PUT/DELETE），对资源进行操作

对资源的理解
就是我们平常上网访问的一张图片、一个文档、一个视频等。这些资源我们通过URI来定位，也就是一个URI表示一个资源。资源是做一个具体的实体信息，它可以有多种的展现方式。而把实体展现出来就是表现层，例如一个txt文本信息，它可以输出成html、json、xml等格式，一个图片他可以jpg、png等方式展现，这个就是表现层的意思。
URI确定一个资源，但是如何确定它的具体表现形式呢？应该在HTTP请求的头信息中用Accept和Content-Type字段指定，这两个字段才是对”表现层”的描述。
对操作的理解
客户端能通知服务器端的手段，只能是HTTP协议。
具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE 。它们分别对应四种基本操作：GET用来获取资源， POST用来新建资源（也可以用于更新资源）， PUT用来更新资源， DELETE用来删除资源。
对于资源的任何操作，都应该映射到HTTP的几个有限的方法（常用的有GET/POST/PUT/DELETE 四个方法，还有不常用的PATCH/HEAD/OPTIONS方法）上面。所以RESTful API建模的过程，可以看作是具有统一接口约束的面向对象建模过程。
按照HTTP协议的规定， GET方法是安全且幂等的， POST方法是既不安全也不幂等的（可以用来作为所有写操作的通配方法）， PUT、 DELETE方法都是不安全但幂等的。将对资源的操作合理映射到这四个方法上面，既不过度使用某个方法（例如过度使用GET方法或POST方法），也不添加过多的操作以至于HTTP的四个方法不够用。
是否全用POST方法实现接口？
在接口设计里面经常会遇到一个问题，即是否全部用POST方法来实现接口，如果图简单省事，那么全部用POST方法是最省事的方式。
对于Get方法相对Post方法来说究竟有哪些优势？网上一段话可以参考如下： GET 的URL可以人肉手工在地址栏输入啊。。。你在地址栏打个POST给我看看。本质上面，GET 的所有信息都在URL ，所以可以很方便的记录下来重复使用。
也就是说通过Get方法可以更好地方便测试，验证，缓存等。
如果不考虑这点，确实可以完全用Post方法来实现所有Rest API接口。但是我们仍然建议对于简单的对象获取，根据Key值获取等仍然可以实现为Get方法。