Mule API AutoDiscovery与Mule API GatewayProxy

Question

什么时候针对API AutoDiscovery使用API代理。在实现了这两者之后，我发现AutoDiscovery也可以应用策略，分析apply所做的事情，唯一的问题是如果使用AutoDiscovery，我不能使用不同的url。API代理的主要优点是，如果我的网关应用程序和Mule实现项目处于不同的子网中，那么如果我的网关服务器受到威胁，就没有人能够访问我的实现网络。

但是，如果接口和实现都在同一个网络中，并且目的只是调用REST端点，那么我们不应该使用API AutoDiscovery。

Mule API网关代理存在的问题

1. 如果无法到达实现服务器，则没有定义的异常处理方法。
2. 没有跨环境移动代理应用程序的定义方法(CI/CD)
3. 如果上述两个问题都有定义的方式，则可以接受额外的HTTP跳

Mule API AutoDiscovery

1. 因为这是在Mule应用程序中，标准异常处理。
2. CI/CD被定义为Mule实施项目。
3. 没有额外的HTTP Hop。
4. 这里唯一的事情是，我们不能更改实现URL，那只是紧密耦合的东西。

谁能提供洞察力，什么时候我们应该去API与AutoDiscovery。另外，目前是否有在API网关项目和CI / CD中执行异常处理的方法？

Answer 1

如果计划将策略应用/取消应用于特定端点，并/或利用API平台上下文中的使用统计信息，则需要API自动发现。Api自动发现是一种元数据，它将HTTP侦听器链接到API管理器上的对应API版本。

例如：

    <api-platform-gw:api id="api.basic.path" apiName="My API" version="1.0.0" flowRef="basic.path">
    </api-platform-gw:api>

    <flow name="basic.path">
        <http:listener config-ref="a.http.config" />
        <set-payload value="Endpoint successfully called." />
    </flow>

自动生成的Mule代理确实定义了自动发现。您还可以开发自己的项目，并通过使用Studio或直接处理XML配置来定义相应的自动发现。

如果您的实现后端不是Mule应用程序(例如，托管在Tomcat服务器中的基于REST的现有API )，则可以使用这些代理。您可以通过自定义异常处理以及Mule端的其他内容丰富逻辑。如果希望在实现后端上更好地处理异常，就必须在那里实现它。

如果您的实现后端是基于Mule的应用程序，则不需要使用代理。对于大多数用例来说，在配置文件中添加相应的自动发现元素就可以了。