WEB開發中，使用JSON-RPC好，仍是RESTful API好？

二者沒有高下之分，無非是一種約定俗成的標準。習慣用RPC就用RPC，能理解REST就用REST。

JSON-RPC比較符合直觀，格式也相對寬鬆；

REST最近正流行，有本身的一套設計規範。

 

REST面對的疑問跟當年剛開始流行面向對象時的狀況是同樣的。

它適合不少狀況，但並不適合全部狀況。

最差的結果就是盲目跟風，又對REST的概念和理念只知其一;不知其二，最後搞出一個半吊子的怪胎，還自我標榜用了流行的RESTful API。

 

REST是一種設計風格，它的不少思惟方式與RPC是徹底衝突的。

RPC的思想是把本地函數映射到API，也就是說一個API對應的是一個function，我本地有一個getAllUsers，遠程也能經過某種約定的協議來調用這個getAllUsers。至於這個協議是Socket、是HTTP仍是別的什麼並不重要；

RPC中的主體都是動做，是個動詞，表示我要作什麼。

而REST則否則，它的URL主體是資源，是個名詞。並且也僅支持HTTP協議，規定了使用HTTP Method表達本次要作的動做，類型通常也不超過那四五種。這些動做表達了對資源僅有的幾種轉化方式。

 

這種設計思路是反程序員直覺的，由於在本地業務代碼中仍然是一個個的函數，是動做，但表如今接口形式上則徹底是資源的形式。

就像面向對象的「萬物皆對象」理論在習慣了純粹面向過程開發的程序員眼裏顯得十分別扭同樣：個人代碼原本就是按順序、循環、分支這麼運行的啊，爲啥非得在很明確的結構上封裝一層一層的基類子類接口，還要故意給兩個函數起同一個名字，調用時才選擇用哪個呢？

 

使用「萬物皆資源」的思想編寫實際項目中的API接口時，最多見的問題就是「這玩意究竟是個什麼資源？………………算了，我就直接寫吧，無論什麼風格了」

• 好比，login和logout應該怎麼REST化？
• 好比，多條件複合搜索在GET裏寫不下怎麼辦？
• 好比，大量資源的刪除難道要寫幾千個DELETE？

其實在理解了REST後，這些都不是什麼無解的難題，只是思惟方式要轉換一下：

• login和logout其實只是對session資源的建立和刪除；
• search自己就是個資源，使用POST建立，若是不需持久化，能夠直接在Response中返回結果，若是須要（如翻頁、長期緩存等），直接保存搜索結果並303跳轉到資源地址就好了；
• id多到連url都寫不下的請求，應該建立task，用GET返回task狀態甚至執行進度；

……等等等。

 

若是隻是規定了一種規範，卻不理解它表相下面的思惟方式，實施中又按照本身的理解隨意變更，那結果確定是混亂不堪的。

固然，API怎麼寫是開發者的自由。但若是一個API在url裏放一堆動詞、資源設計混亂、各類亂用HTTP Method和Status Code，還自稱RESTful API的話，那就像你養了一條狗，還管它叫貓同樣。

這種混搭產物，不如叫它REFU吧。

（Remove Extension From Url：從url裏去掉文件擴展名）

 

前面說了半天REST的理念和不懂REST形成的問題，可是，這並不表明REST比RPC更「高等」，更不是說不理解REST的人是落伍的。

所謂代碼風格、接口形式、各類林林總總的格式規定，其實都是爲了在團隊內部造成共識、防止我的習慣差別引發的混亂。JSON-RPC固然也是有規範的，但相比REST實在寬鬆太多了。

若是一個開發團隊規定必須在url裏寫action，全部請求都是POST，能夠嗎？固然也沒問題，只是不要拿出去標榜本身寫的是RESTful API就行。

規範最終仍是爲了開發者和軟件產品服務的，若是它能帶來便利、減小混亂，就值得用；反之，若是帶來的麻煩比解決的還多，那就犯不上純粹跟風追流行了。