web service介面設計
鑑於ws介面的呼叫方式和普通的api呼叫方式不一樣，因此在設計ws介面時應該有一些其他的考量。以下是我的一些想法，做磚拋了。
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的介面設計就是乙個多方面的考量後的妥協。好的程式設計師就是在種種考量後作出乙個大家覺得都還不錯的方案。
程式就是一門平衡的藝術。
WebService介面設計遇到的問題及解決過程
服務端有這樣乙個類 public class user 定義查詢介面的時候有我想到兩個方案 public user getusers string username,string pwd,int groupid 這樣的定義客戶端呼叫的時候只有兩種結果，一是得到要查詢的資料，一是 得到空陣列，然後缺點...
UI介面設計 介面設計流程
人類社會逐步向非物質社會邁進，網際網路資訊產業已經走入我們的生活。在這樣乙個非物質社會中，與軟體這些非物質產品再也不象過去那樣緊緊靠技術就能處於不敗之地。工業設計開始關注非物質產品。但是在國內依然普遍存在這樣乙個稱呼 美工 工 的意思就是沒有思想緊緊靠體力工作的人。這是乙個很愚昧的做法，愚昧在於稱呼...
介面設計定理
介面設計定理 模組分解原理探索 模組分解原理與三權分立 介面關係穩定原理探索 前面幾篇文章中講過模組分解原理和介面關係穩定原理，這篇文章中將使用模組分解原理和介面關係穩定原理來推導乙個重要的定理 介面設計定理。在講解介面設計定理前，先看一下robert c.martin著的 敏捷軟體開發 一書中提到...