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