在前后端分离的设计中，不管使用什么语言，后端都需要提供 Webj9九游会老哥俱乐部appAPI 给前端使用。如果是一个平台级的产品，还有可能需要将平台的公共 API 提供给第三方系统使用，这些都要考虑到 API 的设计。

本文聊下 API 设计可能遇到的问题以及处理方式。

1、客户端种类比较多，不容易实现差异化。

以我们现在正在做的低代码平台来说，存在的客户端有下面这些：

不同的客户端在调用接口时，输入输出会存在差异，比如：移动端的数据列表功能和结构上比 PC 端要简单很多，如果调用统一的接口，会造成浪费。

2、客户端直接对 API 进行调用。

要解决这些问题，就应该单独提供一个独立的公共 API，而不是直接让第三方开发人员或其他客户端直接访问平台公开的 API ，涉及到独立的公共 API，API 网关就要出场了。

API 网关是一种服务，是外部进入到应用程序内部的入口点。负责请求路由、身份验证、限流、熔断、流量监控等各种功能。

路由请求是 API 网关的核心功能，当网关收到请求时，会去查询路由映射关系，将请求指定到相应的服务。跟 Nginx 的反向代理有点类似。

路由的配置可以是静态的，也可以是动态的，比如在 Ocelot 中，可以在 json 文件中进行路由映射的配置，也可以使用代码的方式按照需求进行动态路由修改。

参考：https://github.com/oec2003/StudySamples/tree/master/UpdateOcelotConfig。

在使用我们平台搭建的业务系统中，打开数据列表的详情，会做下面几件事情：

在 API 网关中可以对客户端提供统一入口调用，将这些来自不同服务的接口进行整合，统一输出，因为网关和服务都在内网，传输速度比较快，和客户端需要同时获取多个 API 请求相比，提升了效率。

作为一个平台，对外提供的公共 API 颗粒度往往不会很细，否则就不具备通用性了。如果针对不同的移动端（安卓、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 的设计还是代码架构的设计，原则其实都差不多，要能够松耦合、易扩展、在满足现有需求的基础上，再多往前想一步，避免过度设计。