RESTful API 标识符的最佳实践答案

【问题标题】：Best practise for RESTful API identifiersRESTful API 标识符的最佳实践
【发布时间】：2018-08-29 14:49:09
【问题描述】：

到目前为止，我看到了这些选项（伪代码）：

A.很简单的 MD5 哈希：

$identifier = MD5(object.id + created_at + app_secret)

=> 4c0dc8d3fdffacb65d04911291aac4cf

B. UUID：

$identifier = uuid()

=> fbcf6520-ab93-11e8-86b4-080027b55b5e

但是哪个UUID version 最有意义？我倾向于 v4。

C.我想为这些 ID 加上前缀，所以我立即知道是什么类型的对象，例如在日志或支持请求中。

$identifier = 'trx_' + uuid()

=> trx_fbcf6520-ab93-11e8-86b4-080027b55b5e

但这是一种不错的风格吗？我可以不使用前缀进行存储，但可以使用前缀公开并允许有或没有前缀的请求。

你最好的做法是什么？

【问题讨论】：

我不太确定您要在这里解决什么问题。 REST 客户端通常不应该关心您的资源标识符，因为它只会调用作为向某些 API 端点发出的请求的响应而收到的 URI。根据定义，URI 是唯一的。因此，支持此功能的资源标识符肯定可以安全使用。如何生成此类标识符完全取决于您，或多或少取决于实施决定。在这里获得 IMO 没有任何好处
首先我想避免双重 ID，而不需要在每次新插入之前检查现有 ID。其次，最好有一个关于 ID 用于何种对象的指标（不太重要）。

【解决方案1】：

这应该不重要。如果我使用类似 UUID 的标识符，我确实认为我会稍微喜欢 UUID 格式，因为它向 API 的用户发出信号“这是一个 UUID”。

这可能对用户有一些小好处，因为如果我看到 UUID，我知道我可以将它作为 128 位整数而不是字符串存储在数据库中。

需要注意的一件事是安全性。您的第一个示例使用了secret 这个词，可能告诉我这些 id 不应该是可猜测的。 UUID 的是可猜测的，而不是加密安全的。

话虽如此，MD5 也是不安全的，所以在这种情况下，您的两个示例都不好。

【讨论】：

感谢您的回答。主要是应该避免暴露 DB ID，并且有人可以通过增加 ID 来太容易地遍历所有对象。但是不需要不可破解的算法。您是否有更好的建议，或者您认为标准 API ID UUID 就足够了？
@ownking，UUID 根本就不好。他们是非常可预测的。即使您不需要超高的安全性，使用安全最佳实践也是一个好主意。查看 openssl_random_pseudo_bytes() 函数。
@ownking 而UUIDs are not completly randomized in Java 我猜 128 位随机性中的 122 位对于任何 API IMO 来说都绰绰有余。
我同意，如果你实现一个简单地向上计数的 UUID 算法，你将很容易受到猜测攻击等，尽管我不会签署 UUID 通常是可预测的声明。如果你使用这样的实现，你基本上是在找麻烦。使用哪种标识符是与客户无关的实现细节，IMO。对于大多数 API，其框架附带的默认 UUID 实现就足够了。对于安全关键的东西，人们可能会改用其他算法
嗨@ownking。是的，UUID 意味着唯一性，而不是让它们难以猜测。一些实现也可能使它们难以猜测。使用 openssl_random_pseudo_bytes 制作自己的 UUID v4 字符串并不难。应该比我在这里写答案和所有这些 cmets 快;)。你不想要 v5，你想要 v4。