RESTful API提供了一些操作。此RESTful API由第三方使用，必须在平台中进行身份验证和授权才能访问API的操作。
第三方需要可靠的数据消费，并且API必须提供发布者/消费者基于模式的解决方案才能使用一些数据。
由于所谓的 API不会重新发明轮子，它即将使用 Windows Azure Service Bus
RESTful API应该抽象实际的服务总线服务。另一方面， Service Bus是在自己的平台上提供可靠消息传递的解决方案。
实际上，Service Bus不是一个独立的服务，但它是某些工作流程的一部分。 第三方不应该拥有Windows Azure凭据。
第三方应使用特定于API的凭据连接到Windows Azure Service Bus，这些凭据可以访问服务总线＆＃39;主题（即消息队列）。
一个。 授权直接访问Windows Azure Service Bus
这似乎是最简单的解决方案。让我们看一下流程：
- 第三方向RESTful API发送请求以获取Windows Azure Service Bus连接字符串 - 凭据 - 。
- 一旦有连接字符串，第三方就会连接到Windows Service Bus，并开始从某个主题订阅接收消息。注意：连接字符串在服务器端加密，只能由接受的客户端解密。
赞成
- 易。 API授权第三方使用Windows Azure Service Bus，它没有其他责任。
- 自有API无法管理主题订阅者的高负载：这由Windows Azure平台处理。
缺点
- 第三方与Windows Azure密切相关。
- 第三方可以轻松绕过RESTful API一段时间。
湾对Windows Azure Service Bus的代理访问
这有可能吗？整个流程将是：
- 第三方要求类似于RESTful的TCP API，以便订阅某些Windows Azure Service Bus主题。
- TCP API建立连接并创建代理，以便将TCP API连接镜像到TCP API到第三方的服务总线I / O.
- 现在，第三方已连接到代理并发送和接收消息。
赞成
- 第三方通过代理连接，这意味着他们不拥有任何Windows Azure凭据，并且他们无法绕过TCP或RESTful API。
- 消息传递不再与Windows Azure完全关联。
缺点
- 如果Windows Azure Service Bus关闭连接会怎样？
- 如果平台代理发生故障会怎样？
℃。 Windows Azure Service Bus服务器包装器
这是定义和流程：
- RESTful API服务器具有Windows Azure Service Bus订阅连接池。
- 第三方订阅了API服务器的TCP套接字或WebSocket 。
- 每当Windows Azure Service Bus收到消息时，它都会路由到第三方连接池，第三方会收到消息。
- 第三方使用RESTful API发送邮件。
赞成
- 第三方完全不了解服务总线技术。
缺点
- 与 b。方法相同。
b。方法可能吗？
您对 c的建议是什么？ Windows Azure Service Bus服务器包装器。您是否发现可避免的战争在正常运行时间方面的可靠性较低，而Windows Azure Service Bus到API以及API与第三方同步的可靠性较低？
我错了，除了这些方法还有其他选择吗？
答案 0 :(得分：2)
最后，我选择了选项a。：授权直接访问Windows Azure Service Bus。
这是使用 Windows Azure访问控制服务。
使用此方法，第三方会收到Azure Service Bus连接字符串，其中包含对某些主题具有特定权限的颁发者（标识）。例如：“消费者只能听”。
有关此内容的更多详情：