我正在钛合金上开发一个应用程序，该应用程序连接到位于 windows azure 的数据库。我想知道：
【问题讨论】：
标签： web-services rest azure azure-storage titanium-alloy
首先让我说我对钛合金不熟悉，但我看到它是一个移动开发框架。我会像对待任何想要使用存储服务的移动解决方案一样回答这个问题。
One - 您可以在 Azure 存储中获取数据，而无需 Web 服务作为代理；但是，这有一些缺点，我将在下面谈到。您当然可以直接使用 REST API 从任何可以说 HTTPS 并解释结果的东西中获取您需要的任何东西。
二 - 直接访问表存储、队列和私有 BLOB 容器的 REST API 的问题是，调用者必须拥有凭据才能获取数据。存储帐户只有一种凭据，即帐户密钥和帐户名称。目前没有对不同服务或服务方面的细粒度控制，因此这意味着拥有这些凭据的任何人都可以对您在该帐户中的数据执行任何他们想要的操作，而不是删除该帐户（尽管他们当然可以删除其中的数据）帐户，甚至用他们整个翻录的电影收藏替换您的数据）。因此，如果您在移动客户端代码中包含您的凭据，它们就会暴露出来，绝对不推荐这样做。
对此的一种选择是使用Shared Access Signatures (SAS)。 SAS 商品会生成一个使用凭据签名的 URL，并且可以在特定时间段内有效。这里的问题是您需要一些东西来为客户端生成 SAS url，这意味着您将在某处拥有 Web 服务。但是，您可以减少访问 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 服务的需求，因为移动服务将扮演该角色，但您需要了解定价模型并根据您自己的场景进行一些比较。
【讨论】：