Azure:是否创建Web服务

时间:2013-08-02 12:38:53

标签: web-services rest azure azure-storage titanium-alloy

我正在开发一种钛合金应用程序,它可以连接到位于windows azure的数据库。我想知道:

  1. 是否有必要创建用于从Azure获取数据的Web服务 存储,因为Windows Azure已经提供REST API
  2. 在我的案例中创建Web服务有哪些优缺点?
  3. 在创建Web服务或直接使用REST API的所有术语(包括性能,开销,安全性等等)中哪种方式更为可取?

1 个答案:

答案 0 :(得分:5)

首先让我说我不熟悉钛合金,但我发现它是一个移动开发框架。我会回答这个问题,就像我希望获得存储服务的任何移动解决方案一样。

一个 - 您可以在Azure存储中获取数据,而无需将Web服务用作代理;然而,这有一些缺点,我将在下面介绍。您当然可以从任何可以说HTTPS并解释结果的任何内容直接获取REST API。

两个 - 直接转到桌面存储,队列和私有BLOB容器的REST API的问题是调用者必须具有获取数据的凭据。存储帐户只有一种凭证,即帐户密钥和帐户名称。目前还没有对服务的不同服务或方面进行细粒度控制,因此这意味着拥有这些凭据的任何人都可以对该帐户中的数据执行任何操作,而不是删除帐户(尽管他们当然可以删除帐户中的数据,甚至用他们整个翻录的Movie集合替换您的数据)。因此,如果您在移动客户端代码中包含您的凭据,则会暴露这些凭据,并且绝对不建议这样做。

选项是使用Shared Access Signatures (SAS)。 SAS提供生成的URL,该URL使用凭据签名,并且可以在特定时间段内有效。这里的问题是你需要为客户生成SAS网址,这意味着你将在某个地方拥有一个网络服务。但是,您可以减少Web服务被点击的次数,因为SAS会生成并使用一段时间,然后您需要再次访问该服务以获取另一个服务。

我要注意这种方法,认为SAS生成的URL只是一个URL。拥有此URL的任何人都可以在创建SAS时为其分配任何权限。当然,如果你正在进行这些调用HTTPS(你应该这样做),那么签名部分就会被加密;但请注意,中间人的攻击实际上仍然可能发生。为了解决这个问题,人们通常会将SAS到期时间确定为几秒或几分钟,但在那时,根据您的负载,您可能也可以通过Web服务路由所有内容,并且认证更加舒适正在发生。例如,如果您的查询之间的负载或时间非常短,则查询的时间比您希望SAS保持有效的时间长,这可能不太合适。我已经看过这个"代客钥匙"模式曾经取得巨大成功所以不要把我的谨慎视为一个标志,这只是一个坏主意,你只需要知道使用它们意味着什么。

三 - 如果你可以将一些处理工作卸载到其他服务器上,那就太棒了。安全方面,您将更安全地通过处理身份验证的Web服务(直接或通过身份提供商)。您可以通过这种方式控制对系统的所有访问权限。性能方面,如果您随后转身并呼叫表存储,您将看到一个命中,因为有多个跃点到位。这可以通过您的服务级别的缓存来缓解(这是一个完全不同的主题)。

您可能想要查看的一个选项是使用Azure Mobile Services。这为您提供了后端。默认情况下,它使用SQL数据库,但使用new Custom API feature,您可以从节点脚本中执行所需操作,包括命中表存储API(有关示例,请参阅此post by Chris Risner)。这种方法将消除您对运行的Web服务的需求,因为移动服务将为该角色提供服务,但您希望了解定价模型并根据您自己的方案进行一些比较。