Google Apps API 模拟 - HTTPS/REST

Question

这似乎是一个已经回答的问题，但我保证不是……至少没有“回答”。

使用 Google Apps for Business。有编写 https/REST 客户端的特定需求 - 不使用 JAVA/PYTHON 或 .NET 等编译代码。在我尝试查询除管理员以外的任何用户的信息之前，浏览 Google 数据 API 文档非常简单。所有需要的范围都已在域级别获得授权（管理 API 访问...等）。每次我尝试查询其他用户的数据时，我都会收到一条消息，您无法访问其他用户的数据。 我知道这听起来很熟悉...但请继续阅读。 在 JAVA、Python 和 .NET 中创建 CLAIM 集以允许模拟有特定的结构。但是，对于直接 HTTPS/REST 调用，似乎没有对应的。

在创建 CLAIM 集时，我尝试同时使用“sub”和“prn”。我已经尝试了管理员用户和要模拟​​的用户的各种组合而没有成功。在这一点上，我相当肯定，在创建用于直接 HTTPS/REST 调用的 CLAIM 集时缺少一个构造。

我正在寻找的是 FLUX Capacitor。

在 JAVA 中，它似乎是：setServiceAccountUser。其他 Google 示例使用类似的结构，但似乎没有任何文档记录 [适用] 用于 HTTPS/REST 调用。这很奇怪，因为似乎所有其他 GData 函数都将/将用于管理访问用户数据。

是否有人仅使用 https/rest 调用成功访问了非管理员（Google Apps for Business）用户数据——而不是使用特定语言的库？内部应用程序必须为数百个用户提供服务。每个用户的授权路由不是一帆风顺...这就是我们在域级别选择委派访问的原因。

任何帮助将不胜感激....即使确认我们正在寻求的东西是不可能的。

TIA...

Answer 1

结果证明我有 FLUX 电容器。我只是没有意识到这一点，因为我只是想一次在我的脚本中做很多事情。 JSON_Request 中的 SUB 值是正确的做法。 PRN 已弃用，其他任何内容都将被忽略。阻止我模仿这种方法的因素之一是我尝试和准成功授权的范围的组合。通过在 Google 的 Playground 中进行的研究和无数小时的研究，我意识到我生成的 TOKEN 看起来不像其他的。芝麻街的歌曲......“这些东西之一不像其他东西......”浮现在脑海中。因此，在将范围（针对相应的 Google API 服务）缩小到最低限度并删除任何没有特别要求的 HTTP 标头值之后；我能够代表我们的用户正确执行脚本。

我收到的令牌看起来更像是 REFRESH TOKEN，而不是初始令牌响应。不值得花时间确定确切的权限。由该令牌启用，但基于相当一致的行为，我计划将逻辑编写到解决方案中，以检测何时收到“无用”令牌响应。

你们现在如何使用 JAVA、.Net、Ruby、Python...等进行编码。可能想知道我为什么不走那些路线。该解决方案的要求之一是它尽可能精简，并相应地尽可能少的依赖项。虽然更麻烦，但这种方法以最原始的形式使用 REST 调用，唯一的依赖是证书文件和相应主机的计算能力（呃，以及它保持时间的能力）。

最终它是一个“最小可行产品”（Eric Ries 的精益创业）......现在是时候让它变得漂亮了 :-)