微服务实战记录（一），URI约定

目的

希望给刚接触服务的同学同一个参考.

公用的标准

• 这些都是公认标准，如需要了解详情百度一下即可。

动作	名称	实例	参数
GET	获取积分信息	/cents/1	1为URI参数
POST	增加积分信息	/cents	正常都是cent实体
PUT	修改积分信息	/cents	正常都是cent实体
DELETE	删除积分信息	/cents/1	1为URI参数

不足于应付的公用标准

• 像上面的标准在实战中，太难使用，把所有的压力都放在了业务层如果user里还包含了Detail业务业务代码及其难看,颗粒化太小导致业务代码需要写很多与业务无法的代码，如下:

//A账转B已经省略无关主题代码
Double tranNumber = 1;
Cent centA = centsRest.findById("A");
centA.setNumber(centA.getNumber() - tranNumber);
Cent centB = centsRest.findById("B");

//忽略为空时的情况了...

//下面用了TCC 关于TCC分布式事务大家可以上网看一下.

TccRequests tccRequests = new TccRequests();
try{
  Tcc  tccA = tccsCentRest.try(centA);  //POST URI:  /tccs/{tccId}/cent   参数:centA
  tccRequests.add(tccA );
  Tcc  tccB = tccsCentRest.try(centB);  //POST URI:  /tccs/{tccId}/cent   参数:centB
  tccRequests.add(tccB);
}catch(Exception e){
  //取消转账，回滚
  tccCentRest.cancel(tccRequests);  //DELETE URI:  /tccs   参数:TccA ID
}
tccCentRest.comfirm(tccRequests);  //PUT URI:         /tccs

//多库多服务问题，在服务本身解决。这个地方跑题了，下次有空我再写另一个文章

补充约定

动作	名称	实例	参数
GET	获取详情	/cents/1/detail	1为URI参数
GET	获取变更信息	/cents/1/changedLogs	page=?&size=?
POST	转账	/cents	centTransferRequest (fromCentId,toCentId,number)
POST	充值	/cents	centChargeRequest (from(...),toCentId,number)
...	...	...	...

• 补充URI后让服务本向提供更多的服务，减低在业务层写大量的服务级代码如上面动作就是优化成:

centTransferRequest.setNumber(1);
centTransferRequest.setFromCentId(A);
centTransferRequest.setToCentId(B);
//搞定，比起上面代码简约了很多
centsTransferRest.transfer(centTransferRequest);

未能很好解决的URI POST PUT问题

• 为了遵循约定，导致有些请求本身带了 centId , 但是在请求时为了规范还是还上了ID 例如
  POST /cents/A/changeLogs , changeLogs实体本身包含了 cnetId
• 如果直接 使用 /cents/changeLogs 和 /cents/{centId} 冲突也相当不优雅.
• 如果使用 /cent/changeLogs .. eeee还是很不优雅，所以勉强了用了重复输参。
• 现最为优雅的 POST /cents changeLogs.

总结

以上都是提供一个参考，更具自已公司的情况自行调整和增加约定。
未优雅的URI之后看看能不能在设计层解决。