RESTful API提供了一些操作。此RESTful API由第三方使用,必须在平台中进行身份验证和授权才能访问API的操作。
第三方需要可靠的数据消费,并且API必须提供发布者/消费者基于模式的解决方案才能使用一些数据。
由于所谓的 API不会重新发明轮子,它即将使用 Windows Azure Service Bus
RESTful API应该抽象实际的服务总线服务。另一方面, Service Bus是在自己的平台上提供可靠消息传递的解决方案。
实际上,Service Bus不是一个独立的服务,但它是某些工作流程的一部分。 第三方不应该拥有Windows Azure凭据。
第三方应使用特定于API的凭据连接到Windows Azure Service Bus,这些凭据可以访问服务总线'主题(即消息队列)。
一个。 授权直接访问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连接字符串,其中包含对某些主题具有特定权限的颁发者(标识)。例如:“消费者只能听”。
有关此内容的更多详情: