Web Service接口设计

1 接口命名的自描述性必须好。有时候查看一个WS会通过wsdl的方式查看,尤其是在跨平台的时候,一个自描述性好的API可以清楚的描述一个Service的功能,便于客户使用。 

2 提供一些粗粒度的接口。在一个WS的调用周期中,SOAP中除去有效负载,光是SOAP头也是占用一定网络开销的,尤其是在有security的情况下。另外,client有可能网络带宽很小,比如只有几k【不是玩笑】。这个时候,让珍贵的网络去传输本质上没有意义的各种协议头就是极大的浪费。因此,可以在一个WS调用时多返回一些数据。 

3 不要使用互通性不好的类做为接口的参数,比如List,Collection,当然数组是通用的。有些类在同一平台当然互通互联的非常好,但是WS的设计是要跨平台的使用,即使现在client和server在同一平台,并不代表以后在同一平台。需求总是变化的。 

4 一个接口在语义上就是一个完整的service,不存在说调用Service A之前必须调用Service B。当应用security时比较特殊,但是security应该做为一种底层框架存在。对于服务编排,我的理解是小服务组合成大服务,而不是几个不完整的服务组合成一个完整的服务。 

5 仔细定义服务的fault。和一般的Exception设计不太一样,边界上fault不宜设计的过于复杂。 

6 当性能有问题时,可以考虑在SOAP上压缩。SOAP消息有时候是会很大的,几M,甚至10M+都是有可能的。而SOAP上一般为字符,字符的压缩比可是很高的。当有二进制文件传输时,可以考虑先转成字符串,比如Base64,然后压缩。 

7 仔细考虑WS上的事务。全局性的事务在技术上相对是比较复杂的,有时只能通过自定义特定的rollback接口实现,增加了server和client的编程复杂性。 

8 永远记着服务只有被调用才有价值,有时候是要用client的需求来驱动一下服务中接口定义的修改。一般先提供服务的一套最小接口集合,在理论上可以完成该服务的任何操作。后期根据client的需求,可以做一些接口级的修改,主要是加一些粗粒度的接口。虽然有可能破坏接口定义的整洁。但是还是那句话,服务只有被调用才有价值,client调用的舒服则更有价值。一般系统的client不会特别多的,这样做是值得的。当然,如果是开发通用的service平台,则更应该考虑service的设计,毕竟,不能为了讨一个客户的欢心,丢到其他所有人。 

WS的接口设计就是一个多方面的考量后的妥协。好的程序员就是在种种考量后作出一个大家觉得都还不错的方案。 

程序就是一门平衡的艺术。

摘自:http://zhang-xzhi-xjtu.iteye.com/blog/353874


你可能感兴趣的:(web Service)