10 個技巧讓你的 RESTful Web 服務更加實用
提示:隨著RESTful Web services的流行程度不斷地上升,開發人員需要知道如何避免開發中的陷阱以及讓開發出來的Web service達到自己能做到的最好程度。
過去的幾年里,我們看到RESTful Web services變得流行起來是有好些原因的。這里有十個技巧你應該要做的,它們能讓你的RESTful Web Service更加高水準并且被其他開發人員使用起來更加簡易。
- 不要尋找一個官方的“REST 標準”
- 還是堅持一些標準
- 確保你的文檔是完美無瑕疵的
- 提供 JSON 輸出
- 不要漏掉 XML
- 理解 HTTP 動詞
- 理解 URI 路由的重要性
- 在版本管理下進行更新維護
- 與你的用戶保持聯系
- 提供示例代碼
REST是一個概念,不是一個標準。因此沒有任何的要求讓你的 RESTful Web service在一個特定的方式下運行。話雖如此,但......
......你的 RESTful Web services 應該遵循至少一些標準!例如用戶認證的OAuth協議、數據交換的JSON和XML、網絡傳輸和自控制的HTTP協議還有URI標準。如果你想要一個更加完整的包,開放數據協議OData是一個有效的選擇(因為它夠大?)。因為沒有人說“REST必須堅持這些標準”這樣的話,并不意味著你就應該按照自己的意愿來。
使用 SOAP 協議的WSDL(Web Service 定義語言)系統,如果你有一個基于WSDL、可以自動生成代碼的工具,那么開發Web Service是相當簡單的。但如果用 REST ,由于services不需要嚴格的定義,并且它們運行在被稱為適當地正確工作的理念上。這意味著service的文檔必須要非常嚴謹。如果你要開發一個 Web Service一定要確保你的文檔百分百的正確。
JSON 已經迅速的變成web上的重要標準。首先,它很方便,因為它可以很容易地讓JavaScript以最少的編碼量來使用Web Service。現在有很多庫可以讓服務端與客戶端的JSON交互工作的非常好。
說到輸出,XML 依然像往常一樣非常重要。為什么要同時支持 XML 和 JSON 呢?因為并不是所有的系統都能使用 JSON 的,但如果一個系統能被稱為 Web Service ,那么它就一定會被規定去處理XML。現在有成堆的遺留系統,舉個例子,它是用XML工作而不是JSON。并且不是所有開發人員都想去mixing和匹配 JSON跟XML的。因此要確保你的Web service系統支持這兩種格式。通過HTTP請求頭的“Accepts”參數來做這種支持而不是通過不同的包含參數的 service URL 來做。
REST Web services 其中一個很核心關鍵的是HTTP協議已經定義好的一大塊功能。而這其中最基本的一部分就是 HTTP 動詞,例如 GET、POST 。而這些基本功能在REST中已經被很好地、充分地理解,一些想法仍然不斷地涌現,例如使用打補丁的方式更新實體中一些特定屬性而不是整個實體。
RESTful Web services 在很大程度上是通過URI來決定干什么的。舉個例子,在一次 GET 請求中,典型的URI路徑會包含一個實體的主鍵值(或者其他標識鍵值)來檢索獲取實體的數據。例如 “http://www.example.com/service/entityname/76″ 將檢索名字為 entityname, 主鍵值為 76 的實體。使用 REST Web services,URI 不僅是一種訪問service的方式,還是控制service和作為傳達你的需求的信號載體。
一件很誘人的事是你只需對唯一一個版本的service做更新維護。但真的不要這樣做!確保你每一次發布更新后都新開一個分支版本來維護。最簡單、最常見的辦法是讓你的service URI 帶上版本號,通常是路徑的一部分。人們最需要的一件事就是使用更新后的軟件沒有任何新的問題或警告出現。
因為用戶不會主動發現你的更新,因此你和你的用戶保持聯系就顯得十分重要了。例如,當你為你的service發布一個新的版本時,你應該給每一個用戶發一封郵件讓他們知道,以及提供舊版本的缺陷信息。
對你的用戶來說你要做的最好的一件事之一就是給他們提供示例代碼。確保你給出的代碼至少包含以下幾個主要的開發語言:Java、.NET、 JavaScript、Ruby還有Python。如果有必要的話,雇傭一個顧問將這些代碼放在一起。因為它對于你的 service 能否被采用是絕對重要的。還要確保你的許可協議可以讓你的用戶沒有任何風險影響地使用你的示例代碼,例如可以使用 MIT 或 BSD 許可協議。
</ol>一些跟 RESTful 相關的開源軟件請看這里。
英文原文