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

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

總結(jié)

以上是生活随笔為你收集整理的一个虐你千百遍的问题：“RPC好，还是RESTful好？”的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。