ESB是SOA解决方案中用于路由,消息转换,协议桥接等的传统中间件.现在,几家供应商提供了一种名为API Gateway的新型中间件解决方案.这些解决方案通常被描述为访问组织公开提供的REST和SOAP服务的中心点.但是,API网关解决方案似乎提供了典型ESB功能的子集.
那么,ESB和API网关之间有什么区别？我什么时候应该使用其中一种？
OpenID 提供商在众所周知的 URL 上发布其元数据。在 Okta 中，它看起来像这样：https://dev-599740.okta.com/oauth2/default/.well-known/oauth-authorization-server AWS Cognito 用户池是否有类似的 URL？如果不是，我如何找到 AWS Cognito 用户池的以下端点？
amazon-web-services amazon-cognito aws-api-gateway ibm-api-management aws-userpools
我们有一个Rest API,它在程序集中只包含对外部Rest服务的"调用",而不需要任何映射,这样API就只能作为网关.
如果直接调用外部服务(例如通过SoapUI),它将返回包含对象数组的JSON响应.该数组嵌套在从根对象开始的3级深度处.
相反,当我们使用相同的请求调用我们的API时,我们得到一个不同的响应:在数组的位置,我们得到一个对应于数组的最后一个对象的对象; 响应中不存在数组的其他对象.
有没有办法解决这个问题？谢谢.
我刚刚发现我刚刚运行的报告中列出了一些弱密码：
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp384r1（相当于 7680 位 RSA）FS 弱 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp384r1（相当于 7680 位 RSA）FS 弱 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp384r1（相当于 7680 位 RSA）FS 弱 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp384r1（相当于 7680 位 RSA）FS 弱 128
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d) 弱 256 TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) 弱 128 TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) 弱 256 TLS_RSA_WITH_AES_128_CBC_SHA256 (0x) 3c) 弱 128 TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 弱 256 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 弱 128
我只配置了这些密码：
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp384r1（等价 7680 位 RSA） FS 256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp384r1（等价 7680 位 …
powershell azure-api-management azure-web-app-service ibm-api-management
我尝试在Azure API管理中设置缓存策略，如下所示：
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" must-revalidate="true" downstream-caching-type="none" caching-type="internal">
<vary-by-query-parameter>KontoNr</vary-by-query-parameter>
</cache-lookup>
<set-backend-service id="apim-generated-policy" backend-id="LogicApp_GeldEinzahlen_APIM_f597e3433e7847cb9d689c3f95bf1d6d" />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/1b7c4ba5-7701-49e7-94d8-5ddbc87f8b6e/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud">
<value>7068cdb6-0e5c-49c5-aaa8-ec8fc941de22</value>
</claim>
</required-claims>
</validate-jwt>
<set-variable name="isKontoNr" value="@(context.Request.MatchedParameters["kontoNr"].ToString().Length != 10)" />
<choose>
<when condition="@(context.Variables.GetValueOrDefault<bool>("isKontoNr"))">
<return-response>
<set-status code="400" reason="Bad Request" />
<set-header name="WWW-Request" exists-action="override">
<value>Generell error="kontoNr invalid"</value>
</set-header>
</return-response>
</when>
</choose>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
<cache-store duration="1000" />
</outbound>
<on-error>
<base />
</on-error>
</policies> …cache-control azure policies azure-api-management ibm-api-management
我正在利用 Azure API 管理解决方案编写概念验证。
我正在尝试编写一项<inbound>执行以下操作的策略：
<send-request>向 API 的身份验证端点发出请求。JObject这就是我目前的政策：
<inbound>
<base />
<!-- Authenticate with the API and get authentication tokens for subsequent calls -->
<send-request mode="new" response-variable-name="auth" timeout="20" ignore-error="true">
<set-url>https://www.service.com/api/authenticate</set-url>
<set-method>POST</set-method>
<set-header name="Content-Type" exists-action="override">
<value>application/json</value>
</set-header>
<set-body>
@{
var credentials = new JObject();
credentials.Add(new JProperty("logonId", "{{API_LOGON_USERNAME}}"));
credentials.Add(new JProperty("logonPassword", "{{API_LOGON_PASSWORD}}"));
return credentials.ToString();
}
</set-body>
</send-request>
<!-- Make …我在 Azure 中遇到了一个设计问题。我创建了一个 .NET Core API 并将其部署为 Azure 中的应用服务。最重要的是，我有一个使用 oAuth 2 保护它的 Azure API 管理实例。我能够通过遵循本教程来实现这一目标：
https://docs.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
因此，API 管理实例受到策略和速率限制的保护，但后端 URL 是完全开放的，不需要身份验证。保护后端 URL 的最佳流程是什么？