DR：在本文中，您将了解API网关如何帮助您保持与旧客户机的API兼容性，同时根据业务的新需求改进产品。如果需要，您可以在这个GitHub存储库中找到这里显示的代码。学习如何在实现新功能、修复错误等的同时保持API向后兼容在推特上留言为什么我需要向后兼容的api？系统不断发展，它们的webapi也是如此。由于它们代表外部客户机与系统交互的接口，因此它们是反映组织中变化的第一行。这种API更改的发生有很多原因。技术进步，业务线的变化，重要的错误修复，等等。很可能这些需求最终会在WebAPI中引入破坏性的更改，而这又意味着破坏了客户机。通常，要使这些客户机再次运行，您需要对它们的源代码进行更改，并且需要发布它们的新版本。有时候，改变是不可避免的，你需要以某种方式或另一种方式来处理它们。然而，有一类问题可以用不同的方式处理，而不是破坏API。在可能的解决方案中，您可以：使用一个超媒体API，它的前言是将理解放在运行时中，而不是提前共享它，它是根据定义准备好的来处理更改的。如果代码正确，客户端可以以非中断的方式处理这种内在的变化，并相应地调整用户体验。使用一个API网关来保持旧的兼容性，同时推出新的更改。这是一种简单但有效的方法，可以屏蔽服务的内部更改，同时保持相同的接口。通过这种方式，您可以在改进服务的同时扩展API的失控性。可以把它看作适配器模式的WebAPI版本。在本文中，您将探讨第二种方法。但是，请记住，超媒体API是一个很好的解决方案，而且大公司已经采用这种方法很久了。快速帮助网关事实证明，Express Gateway是此类任务的完美候选。在本例中，您将学到两件重要的事情：如何将请求的主体形状更改为服务；以及如何修改响应体以使相同的接口对客户端公开。描述问题设想一个简单的用例，其中保持与客户端的API兼容性很重要（可能任何值得注意的应用程序都需要这样做）。假设您有一个由您的内部开发团队编码的服务，它公开了一个API，能够在httpget请求中根据客户的ID返回客户。答案与此类似：{"customerId"："123456789"，"name"："克拉克"，"姓"："肯特"}此外，您的API将使用以下有效负载接受具有POST请求的新客户：{"name"："克拉克"，"姓"："肯特"}然后，此操作将返回创建的客户和生成的customerId以及创建该用户的运算符：{"customerId"："123456"，"createdBy"："vncz"}假设现在，考虑到您的业务正在增长，您决定用第三方云服务取代您自制的客户服务是有意义的，它提供更好的客户管理功能，完全符合您的公司需要。最有可能的是，所提供的API以及所提供的特性在多个部分会有所不同。例如，URL空间将与接受和返回的有效负载不同。在本例中，假设新服务在/v1/cust（而不是/customers）上有一个端点，并且它不接受name和name属性，而是需要一个唯一的fullname属性。另外，由于它是一个外部服务，它不包括任何createdBy属性，因为它是一个只存在于系统中的属性。虽然这些更改很可能对您的内部客户有意义（例如，由于业务需求），但您现有的第三方客户并不太关心此更改。因此，虽然愿意在将来的某个时候迁移，但直接切换开关不是一个选择。使用Express Gateway保持旧API的完整性事实证明，API网关可以为您解决这个问题。作为公共接口和内部服务之间的中间层，快速网关可以在请求和响应的过程中对其进行操作。以下是设置网关需要执行的操作：您需要配置代理策略，以便将对旧端点的请求路由到新的、正确的内部服务。您需要配置bodyModifier策略来修改请求的主体，以便新的客户服务可以使用它。同样，这次您将使用相同的策略来修改response对象，以确保createdBy属性被正确添加。安装快速网关要用expressgateway解决这些问题，您需要安装并使用该框架的beta版本。这个版本很可能很快就会登陆主分支（因此作为正式版本）（支持Express Gateway的团队仍在讨论一些内部需求，因此他们还不能正式实现）。npm安装expressgateway/express gateway#功能/代理事件设置来回代理对象的管道然后，在安装此beta版之后，您将设置两个管道，将请求代理到新的/cust/v1端点：API端点：客户：路径：'/customers*'服务终结点：v1客户：网址：'https://cool.Cloud.service/v1/cust'政策：-代理人-主体修饰符管道：客户：API端点：-顾客政策：-代理人：-行动：服务终结点：v1Cust使用Express Gateway更改请求和响应主体之后，您将使用bodyModifier策略修改请求/响应有效负载，使它们符合新的服务API。-主体修饰符：-行动：请求：添加：-姓名：全名值："请求正文名称+ ' ' + 要求身体姓氏"删除：-姓名：姓名-姓名：姓回应：添加：-名称：createdBy值："请求用户id"上面的配置应该很容易理解。这将连接来自当前请求主体的name和name属性，并从中形成一个新的fullname属性。完成后，它会删除这些属性，因为新服务不需要这些属性。然后，此配置对响应执行类似的任务。也就是说，它基于在网关中注册的当前用户添加createdBy属性。如果现在启动系统，则可以使用以下命令测试新功能：卷曲-X柱：9876/customers/-H"内容类型：application/json"-d'{"name"："Clark"，"name"："Kent"}'尽管内部服务中的代码发生了变化，该系统仍将以与以前相同的方式工作（更重要的是，响应）。旁白：配置Express Gateway以使用Auth0身份管理在安全性方面，Express Gateway和Auth0配合得非常好。现在让我们配置Auth0作为我们的用户管理系统。使用Auth0，我们只需编写几行代码就可以得到可靠的身份管理解决方案，单点登录，支持社交身份提供者（如Facebook、GitHub、Twitter等），支持企业身份提供者（activedirectory、LDAP、SAML、custom等）。如果您还没有Auth0帐户，请立即注册一个免费帐户。在Auth0管理仪表板中，单击"API"菜单项，然后单击"创建API"按钮。你需要给你的API一个名字和一个标识符。名称可以是您选择的任何名称，因此可以根据需要对其进行描述。标识符将用于标识您的API，此字段一旦设置就不能更改。对于我们的示例，我将命名API billings并将其标识为。我还将签名算法保留为RS256并单击createapi按钮。现在，将浏览器指向https://yourAPI.auth0.com/pem（其中yourAPI是创建帐户时选择的Auth0域）并下载公钥文件。这是我们将用来验证Auth0发出的JSON Web令牌（jwt）是否有效的密钥。另存为pubKey.pem公司并将其放在jwt策略的secretrepublickeyfile参数中指定的同一目录中（即项目根目录中名为key的目录中）。API网关现在已正确配置以处理这些场景。在Express Gateway中启用JWT验证expressgateway可以配置为通过在任何管道中安装JWT策略来验证Auth0提供的令牌。政策：#其他政策-智威汤逊：-行动：分泌PublicKeyFile:/key/pubKey.pem公司checkCredentialExistence:错误试驾在项目根目录中使用npmstart启动网关。运行之后，让我们尝试向它发出几个请求：$卷曲：8080个$未经授权您可以看到第一个请求已被拒绝，状态为"未授权"。这是因为我们没有向任何JWT提供请求，所以它没有通过。现在获取任何HTTP客户机，让我们将其配置为针对Auth0启动oauth2.0授权过程。我们可以在应用程序->计费（测试应用程序）->设置中获取所有必要的参数在我的例子中，我将使用curl，但是您可以使用您喜欢的客户机：curl——请求发布\--url https://{AUTH0_DOMAIN}.AUTH0.com/oauth/token\--头"content-type:application/json"\--数据'{"client_id"："{AUTH0_client_id}"，"客户机密"