我们有两个独立的系统通过网络服务进行通信。称它们为前端和后端。许多处理涉及在后端更新列表。比如前端需要更新一个具体的人。目前，我们正在设计后端，我们正在决定界面应该是什么。我们将需要实际的数据库 ID 来更新底层数据库，但我们也看到将数据库 ID 传播给我们的消费者的地方可能不是一个好主意。
强制客户端(即前端)必须将 ID 发送回 Web 服务以更新特定实体的替代方法有哪些？我们试图避免使用 id 的另一个原因是前端通常会保存这些更改以在以后发送。这将要求前端将我们的 ID 保存在他们的系统中，这似乎也是一个坏主意。
我们考虑了以下几点:
1) 将数据库id发回前端；他们必须将这些发回以处理更改
2) 将散列 ID(基于数据库 ID)发送回前端；他们将不得不将这些发回以处理更改。
3) 不要强制客户端发送 id，而是让他们发送原始实体和新实体，并“匹配”到数据库中的我们的实体。他们的原始实体必须与我们保存的实体相匹配。我们还必须定义什么构成了我们的实体和他们的新实体之间的匹配。
最佳答案
前端唯一合理的方法是以某种方式识别数据库中的人员。
匹配完整实体不可靠且不明显；为了将散列 ID 返回到前端，您需要先从前端接收未散列 ID，或者在 ID 下执行一些可恢复的“散列”(更像是“加密”)，所以无论如何都会有一些个人标识符。
恕我直言，它是数据库 ID 还是可以从中提取 ID 的某些数据(加密的数据库 ID)并不重要。为什么您认为让消费者知道数据库 ID 是个坏主意？只要每个人都属于一个消费者，我看不出有任何问题。
如果人(数据库中的对象)和消费者之间存在多对多关系，那么您可以“加密”(广义上)对象 ID，以便加密依赖于消费者。例如，在与消费者通信时，您可以使用数据库中链接(对象和消费者之间)条目的 ID。
如果向消费者发送 ID 对您来说似乎不是个好主意，因为消费者可能会一个一个地枚举所有 ID，您可以通过使用 GUID 而不是整数自动递增 ID 来避免此问题。
PS:至于您的评论，请考虑使用例如GUID 作为对象 ID。 ID 是数据的一部分，而不是模式的一部分，因此在数据库之间迁移时会保留它。这样的 ID 也不会包含敏感信息，因此向消费者(或其他人)透露 ID 是绝对安全的。如果您想防止创建具有相同 SSN 的两个不同的人，只需在您的 SSN 字段中添加一个 UNIQUE 键，但不要将 SSN 用作 ID 的一部分，因为这种方法有很多严重的缺点, 无法透露 ID 是其中最少的。
关于database - 在 Web 服务中处理 ID 的最佳实践是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10209673/