REST Maturity Model
REST等級
之前好奇何謂RPC( Remote Procedure Call)，有查了一些資料。今天剛好看到良葛葛大的這篇文章，來分享討論一下。下圖是2000年Roy Fielding的原圖。
LEVEL 0
只使用一個 URI;多半是全都用POST或用1次的 GET，來提供不同的功能。各個功能怎麼區分?依據傳入的body的內容物來決定，比如URI一樣，但參數裡面有一欄ApiID來區分不同API的這種方式。
又或者webform的submit事件也是很常打到跟原本同樣的URI，區別是第一次進頁面的時候是GET，之後則是所謂的PostBack.
Level 1
URI上能夠區分不同的功能，可稱為多個URI。一個URI就是一種功能。
look like as follows:/addNewArticle/updateArticle/deleteArticle/deleteAllArticle/promoteArticle/promoteAllArticle
Level 2
對同樣資源的不同操作採用同一個URI但不同的HTTP方法。也就是目前主流的:GET /messages 表示取得全部訊息，GET /messages/1 表示取得指定訊息，POST /messages 表示新增訊息、DELETE /messages/1 表示刪除指定訊息這種方式
Level 3
回傳的內容包含了之後可能操作的URI資訊。目前應該算是沒有太統一的規格，有名的包括 HATEOAS。
{
"_embedded": {
"booksList": [
{
"title": "Hitchhiker's Guide to the Galaxy",
"author": "Douglas Adams",
"_links": {
"self": {
"href": "/books/42"
}
}
},
// more books ...
]
}
}不實際?
有些人依然覺得Restful不好用，上面那篇討論串有許多有串的觀點可以看看，比較重要大概是兩個
- RPC(類似Level0或Level1)的處理方式接近於function的概念，等同於把本地開發的共用function給外部呼叫就是api的設計
- restful的定義太單純，我今天1個操作要先查詢再改a後刪b，我他媽的Http方法要用哪個?
以下節錄部分觀點。
有些時候，用REST完成CRUD已經能完成任務了。此時，用REST沒有什麼不好的。但是，現實當中，真正的業務領域一般都會比資源的CRUD複雜的多。
比如面向UI的接口的就要滿足UI需要。此時資源不資源不太重要，而是儘量用少的roundtrip去返回這個界面需要的所有數據。
寫接口的目標各自不同。而REST的目標是“實現互聯網級別的信息共享系統”，這個目標和大部分開發者要實現的目標完全不同
REST是一種設計風格，它的很多思維方式與RPC是完全衝突的。 RPC的思想是把本地函數映射到API，也就是說一個API對應的是一個function，我本地有一個getAllUsers，遠程也能通過某種約定的協議來調用這個getAllUsers。至於這個協議是Socket、是HTTP還是別的什麼並不重要； RPC中的主體都是動作，是個動詞，表示我要做什麼。
而REST則不然，它的URL主體是資源，是個名詞。而且也僅支持HTTP協議，規定了使用HTTP Method表達本次要做的動作，類型一般也不超過那四五種。這些動作表達了對資源僅有的幾種轉化方式。
這種設計思路是反程序員直覺的，因為在本地業務代碼中仍然是一個個的函數，是動作，但表現在接口形式上則完全是資源的形式。 就像面向對象的「萬物皆對象」理論在習慣了純粹面向過程開發的程序員眼裡顯得十分彆扭一樣：我的代碼本來就是按順序、循環、分支這麼運行的啊，為啥非得在很明確的結構上封裝一層一層的基類子類接口，還要故意給兩個函數起同一個名字，調用時才選擇用哪一個呢？
RPC 模型（面向方法）
REST 模型（面向資源）
其它參考文章:
