如今無論是社交媒體平臺還是企業解決方案，Web services都不出不在。為了可以跨平臺使用，如何“暴露”你的APIs就顯得非常重要。當前，很多APIs錶面上聲稱是RESTful，但實際上它們是改進過後的RPC。 ...
原文：http://reynders.co/how-restful-is-your-service/
發表於：2013年9月
如今無論是社交媒體平臺還是企業解決方案，Web services都不出不在。為了可以跨平臺使用，如何“暴露”你的APIs就顯得非常重要。當前，很多APIs錶面上聲稱是RESTful，但實際上它們是改進過後的RPC。
許多聲稱實現了REST風格的服務甚至不知道這個詞是什麼意思，因此我來解釋一下什麼是REST，並且告訴你如何RESTful你的服務。
REST and RESTful
Roy Fielding 的定義, Representational State Transfer（REST） 是分散式系統的一種軟體架構風格。例如Web，它依賴於一個無狀態（stateless），客戶端-伺服器（client-server），可緩存的（cache-able）通信協議，比如HTTP。
/this/does/not/mean/restful, { "neither":"does this" }
擁有清晰流暢的路由並且返回JSON數據並不意味你的服務已經RESTful。只有當採用REST風格並且遵循某些規則時才是真正的RESTful服務。
Fielding指出RESTful所需的6個約束，其中至少5個需被重視：
1. 客戶端-伺服器約束（Client-Server constraint）
使用統一介面隔離客戶端與伺服器。客戶端不必關心業務邏輯和數據存儲，同樣的，伺服器不必考慮用戶界面。
2. 無狀態約束（Stateless constraint）
每次請求都包含伺服器所需的所有信息，伺服器沒有存儲狀態信息。
3. 可緩存約束（Cache-able constraint）
伺服器響應必須能夠顯式或隱式定義自己是可緩存的（cache-able），允許客戶端復用響應，減少與伺服器之間的頻繁調用，以此來提升性能。
4. 分層系統約束（Layered System constraint）
客戶端無需考慮中介組件，如負載平衡和代理，提高系統的可伸縮性。
5. 統一介面約束（Uniform Interface constraint）
客戶端與伺服器之間使用統一的基於HTTP協議的URI來定位資源。如前所述，每個信息都包含足夠伺服器完成後續處理的信息，既 HATEOAS（Hypermedia As The Engine Of Application State）。
6. 按需代碼約束（Code On Demand constraint）
可選約束。在伺服器返回信息之前，客戶端無需知道如何處理這些信息。通常用於向已完成部署的系統中添加功能。
RESTful Web APIs
實現REST的Web應用程式介面和基於HTTP實現RESTful的Web APIs包含以下特性：
- 基本URI，例如：http://api.mysystem.com
- 支持互聯網媒體類型，如：JSON
- 使用HTTP動詞（HTTP verbs: GET, POST, PUT, DELETE）完成操作
- 超文本驅動（Hypertext driven）
RESTful Web API 必須易於使用並且提供完整的幫助文檔。
"If you have to ship an SDK for your RESTful API, it is not a RESTful API" - source
ASP.NET開發團隊提供了一個基於REST原則構建Web API的開發框架，叫做 ASP.NET Web API，點擊獲得擴展閱讀。
小記
前述“約束”並不是一個標準，但不失為構建RESTful風格Web應用的最佳指引。
目前真正實現RESTful思想的應用屈指可數，大部分還是基於HTTP協議改進的RPC。下次你在研究一個新的API時，可以體會一下是否是真正的RESTful。
