NDB urlsafe 密钥和 REST api 请求答案

【问题标题】：NDB urlsafe keys and REST api requestsNDB urlsafe 密钥和 REST api 请求
【发布时间】：2018-04-09 16:01:24
【问题描述】：

我想知道其他人正在做什么以使用数据存储区公开 REST api 端点（使用应用程序引擎标准）。我想使用 urlsafe 密钥，但是 1 - 我不想直接传递这些数据，因为它会带来安全风险，因为应用引擎对应用引擎的调用是通过公共 ip 公开的，以及 2 - 生成的密钥非常很长，当需要将多个作为查询参数传递以形成获取请求时（并且可能会超出浏览器字符限制），这将不是很好。

我在想也许使用某种压缩来压缩 urlsafe 键，这将解决 1 和 2，但想看看是否有更好的方法来创建 REST 端点。或者如果某种类型的压缩方法已经被烘焙到 ndb 中？

【问题讨论】：

API 密钥通常被认为是不安全的。有关详细信息，您可以查看Why and When to Use API Keys 文档页面。
@George ndb urlsafe 密钥与 API 密钥无关，只是在数据存储中检索对象的一种机制。

标签： rest google-app-engine google-cloud-datastore app-engine-ndb google-app-engine-python

【解决方案1】：

Google 在内部使用 HTTPS，所以我不确定您是否需要担心。

此外，您可能应该设计您的应用程序，使密钥不是秘密信息，并且可以安全地公开它们。

我在 REST 调用中使用密钥 ID，我相信它是 12 位数字。只要您知道实体类型，它就可以工作。如果需要指定实体类型，可以在 API 调用中添加另一个参数。

【讨论】：

密钥不一定需要保密，因为无论如何都有足够的身份验证来访问数据存储；我只是不喜欢他们被公开曝光的想法。我一直在使用 ID，但遇到了具有不同祖先的实体的问题，并且在这种情况下生成的 ID 不是唯一的，而键是唯一的。
对，我不使用祖先，所以我没有想到这一点。您必须组合整个谱系的 id，这很麻烦。我想生成 UUID 和其他任何事情一样简单。
是的。然而，键的优点是您有一个直接访问器方法而不使用查询，我相信以这种方式使用键将是一种成本较低的读取操作。
@yoonjesung，这是我不使用祖先的原因之一。使其他事情变得过于复杂，我可以通过偶尔的跨组事务来完成我需要完成的事情。
我明白了。感谢您的洞察力。我主要使用祖先来保证我存储的对象的一致性。