背景
有一个 RESTful API 提供了一些操作。此 RESTful API 由第三方使用，这些第三方必须在平台中进行身份验证和授权才能访问 API 的操作。
第三方需要可靠的数据消费，API必须提供基于发布者/消费者模式的解决方案来消费部分数据。
由于所谓的API 不会重新发明轮子，它即将使用Windows Azure Service Bus。
问题
RESTful API 应该抽象出实际的服务总线服务。另一方面，Service Bus 是在自己的平台中提供可靠消息传递的解决方案。
实际上，Service Bus 不是一个独立的服务，而是一些工作流的一部分。第三方不应拥有 Windows Azure 凭据。
第三方应使用特定于 API 的凭据连接到 Windows Azure 服务总线，该凭据可以访问服务总线的主题（即消息队列）。
可能的解决方案
一个。授权直接访问 Windows Azure 服务总线
这似乎是最简单的解决方案。让我们看看流程：
- 第三方向 RESTful API 发送请求，以获取 Windows Azure 服务总线连接字符串 - 凭据 -。
- 一旦有了连接字符串，第三方就会连接到 Windows 服务总线并开始从某个主题订阅接收消息。注意：连接字符串在服务器端加密，只能由接受的客户端解密。
优点
- 简单的。API 授权第三方使用 Windows Azure 服务总线，它没有其他责任。
- 自己的 API 不管理主题订阅者的高负载：这是由 Windows Azure 平台处理的。
缺点
- 第三方与 Windows Azure 密切相关。
- 第三方可以轻松绕过 RESTful API 一段时间。
湾。代理访问 Windows Azure 服务总线
这有可能吗？整个流程将是：
- 第三方请求一个类似于 RESTful 的 TCP API，以便订阅某些 Windows Azure 服务总线主题。
- TCP API 建立连接并创建代理，以便将 TCP API 连接到服务总线 I/O 镜像到 TCP API 到第三方。
- 现在第三方连接到代理并发送和接收消息。
优点
- 第三方通过代理连接，这意味着他们不拥有任何 Windows Azure 凭据，也无法绕过 TCP 或 RESTful API。
- 消息传递不再完全依赖于 Windows Azure。
缺点
- 如果 Windows Azure 服务总线关闭连接会发生什么？
- 如果平台代理出现故障会发生什么？
C。Windows Azure 服务总线服务器包装器
这是定义和流程：
- RESTful API 服务器具有 Windows Azure 服务总线订阅连接池。
- 第三方订阅了 API 服务器的 TCP 套接字或 WebSocket。
- 每当 Windows Azure 服务总线有消息时，它都会被路由到第三方连接池，第三方会收到消息。
- 第三方使用 RESTful API 发送消息。
优点
- 第三方完全不知道服务总线技术。
缺点
- 与b 相同。方法。
问题
是b。方法可能吗？
你对c有什么建议。Windows Azure 服务总线服务器包装器。您是否发现在正常运行时间和 Windows Azure 服务总线与 API 和 API 与第三方同步方面的可靠性越低，这是一场可以避免的战争？
我错了，这些方法还有其他选择吗？