一個虐你千百遍的問題：“RPC好，還是RESTful好？”

看到知乎上有這樣一個問題
WEB開發中，使用JSON-RPC好，還是RESTful API好？
還有其他優秀的推薦方案嗎？
-----------------------------------------------------------------
先科普一下
REST 和 RESTful 什么區別？
REST，即Representational State Transfer的縮寫。翻譯過來是表現層狀態轉換。
如果一個架構符合REST原則，就稱它為RESTful架構。
啥叫json-rpc？
接口調用通常包含兩個部分，序列化和通信協議。常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等；通信比較流行的是http、soap、websockect，RPC通常基於TCP實現，常用框架例如netty。
RESTful通常采用http+JSON實現。
JSON-RPC是指通信協議采用二進制方式，而不是http，序列化采用JSON的形式。
被贊的最多的一個回答
翁偉 262 人贊同
JSON-RPC比RESTful API好很多。
======
我厭惡restful API如同我厭惡OOP；但與其說我厭惡restful，倒不如說我厭惡鼓吹restful API的一些偽·程序員。
很多鼓吹restful API的程序員，實際上並不理解restful的設計理念，純粹是在人言亦言，隨便看了幾篇網文在說restful，自己便也更着鼓吹。
做為一個合格的技術人員，最基礎的要求是要對自己所使用的技術有了解，明白各種技術的適用場景，然后因地制宜。
restful首先是要求必須把所有的應用定義成為“resource”，然后只能針對資源做有限的四種操作。
這是對API一個非常糟糕的抽象，有太多現實中需要的API，無法順當的融入到restful所定義的規范中。
比方說，user login / resetpassword等等。
restful的信徒，他們會說可以根據這個那個規范，把login / password等也納入為某種資源，然后進行增刪改查。這在我看來，純粹是在解決一些原本不存在，根本不需要解決的問題，純浪費。
所有的接口，服務器端原本就存在有相應的函數，它們本來就有自身的命名空間，接受的參數、返回值、異常等等。
采用輕便的方式暴露出來即可。
無需把一堆函數重新歸納到“資源”，再削減腦袋把所有的操作都映射為“增刪改查”。
對應到web上，rpc的成熟方案非常多，有古老的soap，也有輕量的json rpc。
JSON rpc基本上僅是要求所有的請求必須有msg id，有函數名，然后可定義參數，並且區分返回值與異常；也可定義『命名空間』來對函數模塊做划分。
這與大多數語言的模塊、函數定義相符，使用起來是非常便利的。
很多json rpc是供web前端ajax調用，若前端調用抽象得當，調用遠程API，實際上與調用本地函數無甚區別。
實際上，json rpc也未必需要跟http綁定，即便是在web上，它也可以走web socket，這樣子，前端可以使用同一web socket管道批量發送請求，而服務器端亂序返回結果時，前端也可以根據msg id做准確的回調。
websocket，批量調用，亂序返回，這些都可以顯著提高API的輸出吞吐，這些是在json rpc的設計考量內。
調用更方便，性能也更好，兩全其美是完全可能的。
想當然的為了“快”，為了“簡單”就必須犧牲別的，這是嚴重的思維誤區。
有些方案，純粹就是糟糕的方案。
restful API僅適用與業務非常簡單的場景，比方說，就是為了提供少量數據表單的增刪改查。而這種場景實在是太過簡單，實際中幾乎找不到。
----------------------------------------------------------
我的觀點
實際上，這個問題本質上是RESTful和RPC之爭。這兩種風格都是隨着架構發展而來。分別適用不同的場景。
http vs 高性能二進制協議
http相對更規范，更標准，更通用，無論哪種語言都支持http協議。如果你是對外開放API，例如開放平台，外部的編程語言多種多樣，你無法拒絕對每種語言的支持，相應的，如果采用http，無疑在你實現SDK之前，支持了所有語言，所以，現在開源中間件，基本最先支持的幾個協議都包含RESTful。
RPC協議性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能達到http的二倍。響應時間也更為出色。千萬不要小看這點性能損耗，公認的，微服務做的比較好的，例如，netflix、阿里，曾經都傳出過為了提升性能而合並服務。如果是交付型的項目，性能更為重要，因為你賣給客戶往往靠的就是性能上微弱的優勢。
RESTful的規范到底是不是雞肋？
我認為，微服務的盛行，開放平台的盛行，的確讓RESTful過於“流行”了。你可以看看，無論是Google、Amazon、netflix（據說很可能轉向grpc），還是阿里，實際上內部都是采用性能更高的RPC方式。而對外開放的才是RESTful。
如果你的應用非常簡單，無論用哪種都無所謂了，基本都能滿足要求。
關於無狀態、冪等
這個跟你是否采用RESTful無關，主要還是看接口內部實現，所以，把這個作為RESTful優點的可以閉嘴了。
安全性
顯然，基於Http更安全一些，默認80端口，防火牆友好。
RESTful也分為嚴格的和自由的
RESTful還有個好處是制定了一系列規范，但是大多數使用者都是自由風格的，根本不是嚴格按照RESTful規范實現。當然存在就是道理，這樣做更高效，但是不夠通用。
無疑，嚴格按照資源抽象，API看起來更清晰，更容易被大家理解。同時，開發人員的復雜度也更高。
最后建議
對外開放給全世界的API推薦采用RESTful，是否嚴格按照規范是一個要權衡的問題。要綜合成本、穩定性、易用性、業務場景等等多種因素。
內部調用推薦采用RPC方式。當然不能一概而論，還要看具體的業務場景。
另外一個因素是人，關鍵是你有什么人，postgresql、mysql都有用的不錯的，遷來遷去，關鍵是你的人對哪個更熟悉。

感興趣的可以去知乎看原文：http://www.zhihu.com/question/28570307