Mule API AutoDiscovery vs Mule API GatewayProxy

Question

什么时候应该使用针对API自动搜索的API代理。在实现两者之后，我发现AutoDiscovery也可以应用API Gateway所做的策略和分析，但唯一的是如果使用AutoDiscovery，则无法使用其他网址。如果我的网关应用程序和Mule实施项目位于不同的子网中，那么API代理的主要优点是，如果我们的网关服务器受到威胁，则无法访问我的实施网络。

但是，如果接口和实现同一网络中，而目的仅仅是调用REST端点，难道我们不应该用API自动搜索去。

问题与骡子API网关代理

1. 没有明确的异常处理的方式，如果我们不能够达到实现服务器。
2. 没有定义不同环境移动代理应用程序（CI/CD）
3. 额外的HTTP啤酒花的方式，可以是可接受的，如果在上述2个问题有一个确定的方式

骡API自动搜索

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

有人可以提供有关我们应该何时应用API网关与自动搜索的见解。目前还有一种在API网关项目和CI/CD中执行异常处理的方法吗？

Answer 1

如果您打算向特定端点应用/取消应用策略，和/或利用API平台上下文中的使用情况统计信息，则需要API Autodiscovery。 Api Autodiscovery是一种将HTTP（s）侦听器链接到API Manager上的对应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> 

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

如果您的实现后端不是Mule应用程序（例如，托管在Tomcat服务器中的现有基于REST的API），则这些代理意味着使用。您可以通过自定义异常处理来丰富逻辑，并在Mule方面进行其他操作。如果您希望在实现后端上执行更好的异常处理，则必须在此处实现它。

如果您的实施后端是骡子基于应用程序，使用代理不是必需的。对于大多数使用情况来说，在配置文件中添加相应的自动发现元素将会有所斩获。