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