904
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的接口設計就是一個多方麵的考量後的妥協。好的程序員就是在種種考量後作出一個大家覺得都還不錯的方案。
程序就是一門平衡的藝術。
摘自：https://zhang-xzhi-xjtu.iteye.com/blog/353874
最後更新：2017-04-02 22:16:21