目的
希望给刚接触服务的同学同一个参考.
公用的标准
- 这些都是公认标准，如需要了解详情百度一下即可。
| 动作 | 名称 | 实例 | 参数 |
|---|---|---|---|
| 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之后看看能不能在设计层解决。
