在前后端分離的設(shè)計(jì)中，不管使用什么語(yǔ)言，后端都需要提供 WebAPI 給前端使用。如果是一個(gè)平臺(tái)級(jí)的產(chǎn)品，還有可能需要將平臺(tái)的公共 API 提供給第三方系統(tǒng)使用，這些都要考慮到 API 的設(shè)計(jì)。
本文聊下 API 設(shè)計(jì)可能遇到的問(wèn)題以及處理方式。
問(wèn)題
1、客戶(hù)端種類(lèi)比較多，不容易實(shí)現(xiàn)差異化。
以我們現(xiàn)在正在做的低代碼平臺(tái)來(lái)說(shuō)，存在的客戶(hù)端有下面這些：
- Web 端應(yīng)用程序
- 移動(dòng)端的應(yīng)用程序
- 第三方開(kāi)發(fā)人員編寫(xiě)的應(yīng)用程序
- 自定義組件（符合規(guī)范的 Vue 前端組件，可以無(wú)縫和平臺(tái)進(jìn)行整合）
- 平臺(tái)配置的腳本（直接配置在平臺(tái)中，可以調(diào)用接口、處理界面元素）
不同的客戶(hù)端在調(diào)用接口時(shí)，輸入輸出會(huì)存在差異，比如：移動(dòng)端的數(shù)據(jù)列表功能和結(jié)構(gòu)上比 PC 端要簡(jiǎn)單很多，如果調(diào)用統(tǒng)一的接口，會(huì)造成浪費(fèi)。
2、客戶(hù)端直接對(duì) API 進(jìn)行調(diào)用。
- API 如果拆分的比較細(xì)，一次操作會(huì)發(fā)出多個(gè)請(qǐng)求才能拿到想要的數(shù)據(jù)，效率比較低
- 當(dāng)需要多個(gè)請(qǐng)求時(shí)，還需要在客戶(hù)端進(jìn)行邏輯的組合，這樣每個(gè)客戶(hù)端可能都有一套自己的邏輯，不容易維護(hù)
- 服務(wù)如果進(jìn)行拆分和合并，客戶(hù)端代碼需要同步進(jìn)行修改
- 如果 API 進(jìn)行了修改，第三方調(diào)用方需要配合修改，但這中間的溝通成本會(huì)很高，有時(shí)甚至不可行
要解決這些問(wèn)題，就應(yīng)該單獨(dú)提供一個(gè)獨(dú)立的公共 API，而不是直接讓第三方開(kāi)發(fā)人員或其他客戶(hù)端直接訪問(wèn)平臺(tái)公開(kāi)的 API ，涉及到獨(dú)立的公共 API，API 網(wǎng)關(guān)就要出場(chǎng)了。
API 網(wǎng)關(guān)
API 網(wǎng)關(guān)是一種服務(wù)，是外部進(jìn)入到應(yīng)用程序內(nèi)部的入口點(diǎn)。負(fù)責(zé)請(qǐng)求路由、身份驗(yàn)證、限流、熔斷、流量監(jiān)控等各種功能。
路由請(qǐng)求
路由請(qǐng)求是 API 網(wǎng)關(guān)的核心功能，當(dāng)網(wǎng)關(guān)收到請(qǐng)求時(shí)，會(huì)去查詢(xún)路由映射關(guān)系，將請(qǐng)求指定到相應(yīng)的服務(wù)。跟 Nginx 的反向代理有點(diǎn)類(lèi)似。
路由的配置可以是靜態(tài)的，也可以是動(dòng)態(tài)的，比如在 Ocelot 中，可以在 json 文件中進(jìn)行路由映射的配置，也可以使用代碼的方式按照需求進(jìn)行動(dòng)態(tài)路由修改。
參考：https://Github.com/oec2003/StudySamples/tree/master/UpdateOcelotConfig。
組合多個(gè)服務(wù)
在使用我們平臺(tái)搭建的業(yè)務(wù)系統(tǒng)中，打開(kāi)數(shù)據(jù)列表的詳情，會(huì)做下面幾件事情：
- 獲取按鈕配置
- 獲取表單模型
- 獲取表單字段權(quán)限（根據(jù)不同的人員，獲取的是不同流程節(jié)點(diǎn)的權(quán)限）
- 獲取表單數(shù)據(jù)
在 API 網(wǎng)關(guān)中可以對(duì)客戶(hù)端提供統(tǒng)一入口調(diào)用，將這些來(lái)自不同服務(wù)的接口進(jìn)行整合，統(tǒng)一輸出，因?yàn)榫W(wǎng)關(guān)和服務(wù)都在內(nèi)網(wǎng)，傳輸速度比較快，和客戶(hù)端需要同時(shí)獲取多個(gè) API 請(qǐng)求相比，提升了效率。
專(zhuān)屬 API
作為一個(gè)平臺(tái)，對(duì)外提供的公共 API 顆粒度往往不會(huì)很細(xì)，否則就不具備通用性了。如果針對(duì)不同的移動(dòng)端（Android/ target=_blank class=infotextkey>安卓、iOS）、或者特定的第三方平臺(tái)，有一些細(xì)節(jié)上的區(qū)別。
網(wǎng)關(guān)可以為不同類(lèi)型的客戶(hù)端提供獨(dú)立的 API。
一些擴(kuò)展能力
- 身份認(rèn)證
- 訪問(wèn)授權(quán)
- 限流
- 熔斷
- 緩存
- 指標(biāo)收集
- 日志記錄
這些擴(kuò)展能力并非只有在 API 網(wǎng)關(guān)中才能實(shí)現(xiàn)，在后端服務(wù)中一樣可以。但有些能力放到 API 網(wǎng)關(guān)中會(huì)更合適。
例如：身份認(rèn)證、限流、熔斷等，就是在請(qǐng)求還為觸及服務(wù)時(shí)就已經(jīng)處理了，會(huì)更加安全，也會(huì)讓后端服務(wù)更穩(wěn)固。
網(wǎng)關(guān)的選擇
在 .NET Core 中可以選擇的開(kāi)源網(wǎng)關(guān)產(chǎn)品有：Ocelot、Kong、Envoy 等。
Ocelot：是一個(gè)基于.NET Core的輕量級(jí) API 網(wǎng)關(guān)，用于構(gòu)建和管理微服務(wù)架構(gòu)中的 API 網(wǎng)關(guān)。作為一個(gè)開(kāi)源項(xiàng)目，Ocelot 提供了一種靈活、可擴(kuò)展的方式來(lái)集中處理請(qǐng)求路由、認(rèn)證授權(quán)、請(qǐng)求轉(zhuǎn)發(fā)、負(fù)載均衡和緩存等功能。
Kong：是在 Nginx 中運(yùn)行的 Lua 程序。得益于 Nginx 的性能優(yōu)勢(shì)，Kong 相比于其它的開(kāi)源 API 網(wǎng)關(guān)來(lái)說(shuō)，性能方面是最好的。由于大中型公司對(duì)于 Nginx 運(yùn)維能力都比較強(qiáng)，所以選擇 Kong 作為 API 網(wǎng)關(guān)，無(wú)論是在性能還是在運(yùn)維的把控力上，都是比較好的選擇。
Envoy：是一個(gè)開(kāi)源的高性能代理和通信中間件，專(zhuān)為云原生應(yīng)用程序設(shè)計(jì)。它由 Lyft 開(kāi)發(fā)并于 2017年成為 Cloud Native Computing Foundation（CNCF）的畢業(yè)項(xiàng)目之一。雖然 Envoy 本身是用 C++ 編寫(xiě)的，但它可以與任何語(yǔ)言和框架進(jìn)行集成，包括 .NET Core。
網(wǎng)關(guān)的選擇需要能解決當(dāng)前面臨的問(wèn)題。關(guān)于各種網(wǎng)關(guān)的使用方式，以及優(yōu)缺點(diǎn)的對(duì)比，后面再進(jìn)行詳細(xì)介紹。
最后
不管是 API 的設(shè)計(jì)還是代碼架構(gòu)的設(shè)計(jì)，原則其實(shí)都差不多，要能夠松耦合、易擴(kuò)展、在滿足現(xiàn)有需求的基礎(chǔ)上，再多往前想一步，避免過(guò)度設(shè)計(jì)。
