本文主要探討RPC和RESTFul兩種API風(fēng)格的特點(diǎn)以及在開發(fā)中應(yīng)該如何進(jìn)行技術(shù)選型，截取了部分網(wǎng)上社區(qū)，文章關(guān)于API設(shè)計(jì)的想法和觀點(diǎn)供讀者參考取舍。

1，背景簡述

API學(xué)名：應(yīng)用程序接口（Application Programming Interface）

通俗的打個(gè)比方，人與人之間通過語言來交流，而程序和程序之間通過API來交流。

目前市場主流的API設(shè)計(jì)包括RPC，RESTFul，GraphQL等設(shè)計(jì)思路，關(guān)于API風(fēng)格優(yōu)劣，好壞眾說紛紜，但客觀來說：RPC資歷最老，并沿用至今，RESTFul后來者居上，火了好大一陣，最新的GraphQL據(jù)說會在Githup下一版投入使用。API的選擇問題絲毫不亞于跨端框架Flutter和RN的激烈斗爭。但筆者堅(jiān)持認(rèn)為：軟件開發(fā)沒有銀彈，技術(shù)終究會被歷史裹挾，不斷推進(jìn)，但對于開發(fā)者來說，也許沒有永恒的銀彈，但在當(dāng)下選擇適合自己業(yè)務(wù)場景的技術(shù)卻是舉足輕重。

本篇文章主要探討前兩種API設(shè)計(jì)的優(yōu)缺點(diǎn)以供讀者進(jìn)行技術(shù)決策的參考。

2，RPC以動(dòng)詞為核心

2.1 命名風(fēng)格

RPC 形式的API通常是動(dòng)賓結(jié)構(gòu)：

getUserInfo，createUser，getUserById

由于接口的個(gè)性化需求，添加新功能時(shí)，API中可能會引入其他的動(dòng)詞或介詞如By，With，create等等，這也是RESTFul征討RPC的主要原因

• 一是嫌它丑
• 二是認(rèn)為它不夠通用（在服務(wù)端更新了之后，客戶端也需要閱讀文檔，適應(yīng)服務(wù)端）

3.1 常用實(shí)踐

• 面向接口編程

  在參數(shù)傳遞過程中使用接口而不是實(shí)現(xiàn)類，使程序更加靈活可擴(kuò)展

  例如使用Map而不是HashMap，TreeMap，使用List而不是ArrayList，LinkedList

• 方法重載

  通俗來講，省去了方法名，使得API調(diào)用更加方便

3，RESTFul以名詞為核心

“表述性狀態(tài)轉(zhuǎn)移”

3.1命名風(fēng)格

/admin/users （查詢用戶） 
/admin/users （新增用戶） 
/admin/users （更新用戶） 
/admin/users （刪除用戶） 

雖然有點(diǎn)不太恰當(dāng)，但RESTFul的以名詞為核心的API風(fēng)格其實(shí)就是把動(dòng)詞使用請求方法代替了，所謂的表述性狀態(tài)轉(zhuǎn)移實(shí)際上就是用請求方法屏蔽掉了API的部分實(shí)現(xiàn)。但不可否認(rèn)的是，這樣對于API的可讀性的確有顯著提高。

 @RequestMapping(value = "/user", method = RequestMethod.GET)
 @RequestMapping(value = "/user", method = RequestMethod.DELETE)

然而，RESTFul并不能很好適應(yīng)API的復(fù)雜性，例如常見的登錄注冊功能使用RESTFul的風(fēng)格難以對資源進(jìn)行抽象。RESTFul對于單資源的增刪改查的確可以實(shí)現(xiàn)API的升級，但由于其接口粒度過粗，對于多資源的查詢操作難以設(shè)計(jì)出合理的API。

3.2 常用實(shí)踐

• 資源名使用復(fù)數(shù)

  不要混淆名詞單數(shù)和復(fù)數(shù)，為了保持簡單，只對所有資源使用復(fù)數(shù)。

• 避免多級 URL（存在爭議）

  獲取某個(gè)作者的某一類文章
  GET /authors/12/categories/2
  
  GET /authors/12?categories=2
  
  ==============================
  查詢已發(fā)布的文章
  GET /articles/published
  
  GET /articles?published=true
  

4，如何對RPC和RESTFul進(jìn)行技術(shù)決策？

• 可讀性

  相對于RPC，RESTFul風(fēng)格的API具有更強(qiáng)的可讀性，更加利于理解

• 兼容性

  RESTFul相對于RPC接口，粒度更大。

  RESTFul適合應(yīng)用于開發(fā)API的增刪改查，而RPC適合更加精細(xì)化可定制的業(yè)務(wù)場景

在實(shí)現(xiàn)開發(fā)接口API，RESTFul有更好的表現(xiàn)。

在實(shí)現(xiàn)業(yè)務(wù)系統(tǒng)，RPC具有更高的定制化能力。

5，關(guān)于API接口設(shè)計(jì)的一些討論

參考文章

淺談如何設(shè)計(jì)API

restful與rpc風(fēng)格

REST與RESTFul API最佳實(shí)踐

API 設(shè)計(jì)最佳實(shí)踐的思考

RESTful API 最佳實(shí)踐