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