后端ID是公开的还是不公开的？

根据这个人说的话：http : //toddfredrich.com/ids-in-rest-api.html

假设他关于使用UUID识别api资源是正确的。然后我遇到麻烦，尝试以这种方式实现它，这是：

class FooEntity {

    final String id = null;  //auto-generated by my backend (mongodb), not shared
    final UUID uid = UUID.randomUUID();  //the resource id
}

（在客户端和服务器之间，发送和接收DTO，而不是数据库实体。）

现在的问题是，这id不再有用，因为我不再使用它。客户端发出请求，uid所以为什么还要打扰2个id？然后我们回到开始的同一期。如果我将UUID设置为主键（_id），那么我会将后端ID公开。

除此之外，还有效率主题。我已经读过，通过ObjectId进行索引比UUID效率更高。

我将后端ID公开

通过请求返回实体时，您还必须使用什么其他方法来标识您的实体？这比SSN或类似的标识符完全合法和安全。这就是Todd所谈论的-使识别技术和实体保持中立，他是对的。

效率主题

如果ObjectId确实有效得多，则可以保留两个标识符。从理论上讲，使用UUID作为标识符总是比数据库自动增量器更好。

不，就数据库而言，外部API不会暴露任何内部结构。身份证没有情报。它们甚至在现实世界中都不是唯一的。ID：无处不在47 您可以访问某些实体，并且可以操纵数据，但是该数据库是将所有内容存储在一个表中还是存储在十个表中，是否将增量ID用作PK并与FK相关，这是您永远不会知道的。

如果可以，GetUserAccountByID（12345）只是要求某人尝试GetUserAccountByID（12346）。即使由于其他安全措施而无法使用，也不要试图通过在帐户：12346上索取信息来对公司进行社交入侵。除非您致电DBA并愿意等待2个星期才能回应;）

因此，请创建GUID，无论您认为合适还是其他自然键（例如电话号码或电子邮件地址）。在表中的字段上放置唯一约束，以避免在进行某些合并数据尝试时进行一些晦涩的复制和粘贴尝试。

这不是多余的。这两个字段有不同的用途。

关于效率ID与UUID，除非您有涉及多个表且每个表具有数百万条记录的多个联接，否则差别不会太大。如果您不直接在服务器端进行检查/应用，那么使用UUID会使您的应用程序更难进行剪贴：

• GET [...] / 1
• 得到[...] / 2

使用ID时非常容易，如果您改用UUID，则它是刮板的一种较少选择。

可以将ID视为应用程序数据库实例内部的内容。该句子中有三个重要的单词：

• 应用程序：由于它是您的模型，因此您的表可能仅由该应用程序使用
• 数据库：如果多个应用程序针对同一个数据库使用了它，那您就可以了
• （数据库的）实例：如果您有分布式系统，则id将彼此冲突，并且它们对于不使用数据库实例的任何其他系统/应用程序将毫无意义。UUID是该特定情况的解决方案。

根据个人喜好：我希望有一个简单的ID和一个唯一的业务ID（邮件，登录名，...）。因此，如果我必须交换数据，我将使用业务ID，因为目标系统可能无法处理UUID，但他很可能（永远不会说...）会很好地处理唯一的业务密钥。