我们有两个独立的系统通过Web服务进行通信。称它们为前端和后端。许多处理涉及在后端更新列表。例如，前端需要更新特定的人员。目前，我们正在设计后端，我们正在决定接口应该是什么。我们将需要实际的数据库ID来更新底层数据库，但是我们也会看到向客户传播数据库ID的位置可能不太合适。什么是在Web服务中处理ID的最佳实践？
强迫客户端（即前端）必须发送id到Web服务以更新特定实体的一些替代方法是什么？我们试图避免ID的另一个原因是前端经常会将这些更改保存在稍后的日期。这需要前端将我们的ID保存在他们的系统中，这似乎也不是一个好主意。
我们曾考虑以下几点：
1）发送数据库ID回到前端;他们将不得不发送这些回来处理更改
2）发送散列ID（基于数据库ID）回到前端;他们将不得不将这些邮件发回来处理更改。
3）不要强迫客户端发送标识符，而是让他们发送原始实体和新实体，并将“匹配”发送到数据库中的实体。他们的原始实体必须与我们保存的实体相匹配。我们还必须确定什么构成我们的实体与其新实体之间的匹配。
对于前端来说，唯一合理的方法就是在数据库中识别人员。
匹配完整的实体是不可靠的，并不明显;为了将哈希ID返回到前端，您需要首先从前端接收未哈希ID，或者在ID下执行一些可恢复的“哈希”（更像是“加密”），所以无论如何都会有一些人标识符。
恕我直言，无论它将是一个数据库ID还是某个可从中提取ID的数据（加密数据库ID）都无关紧要。你为什么认为知道数据库ID的消费者会是个坏主意？只要每个人都属于一个消费者，我就没有看到任何问题。
如果人员（数据库中的对象）与消费者之间存在多对多关系，那么您可以“加密”（广义上）对象ID，以便加密将与消费者相关。例如，在与消费者沟通时，您可以使用DB中链接（在对象和消费者之间）条目的ID。
如果由于消费者可能逐个枚举所有ID而将消息发送给消费者似乎不是个好主意，可以使用GUID而不是整数自动递增的ID来避免此问题。 PS：关于您的评论，请考虑使用例如GUID作为对象ID。该ID是数据的一部分，而不是模式的一部分，因此在数据库之间迁移时将保留该ID。这样的ID也不会包含敏感信息，所以向消费者（或其他人）透露ID是完全安全的。如果您想阻止创建具有相同SSN的两个不同人员，只需在您的SSN字段中添加一个UNIQUE密钥，但不要将SSN用作ID的一部分，因为此类方法有许多严重的缺点，无法显示ID是他们中最小的。
我们一直犹豫发送数据库ID的主要原因是它将这两个系统结合在一起。如果我们决定更改数据库，这可能会影响前端。另外，可以设想，如果id是例如自然键（例如基于ssn），那么id可以包含一些敏感信息。我们正在努力务实，但也遵循最佳做法。感谢您的意见。 – tjg184 2012-04-18 13:05:36
1）更改数据库不应更改ID。 2）ID不应该是自然键;出于某种原因，如果SSN会改变（例如，客户错误地输入了错误的SSN），或者您需要支持来自其他国家的客户？你从错误的角度看待问题;首先你实现了错误的数据结构（带有包含敏感信息的ID并且随着DB返工而发生变化），然后你试图实现某种方式来处理对象而不知道它们的ID。 – penartur 2012-04-19 08:12:47
从我的角度来看，记录的ID并不会向任何人传达任何敏感信息。
因此，将数据库ID发送到前端（以及一般情况）没有问题。
唯一值得关注的是数据库一致性问题，但我看不到任何问题。
此外，从性能来看，它好得多，因为您无需查询数据库上的属性以查找数据库ID。
此外，如果您发送了ID的散列，则无法从散列中提取ID。
你必须找到在哈希匹配数据库中的ID，这是不好的IMO
所以：
我们也看到传播数据库ID给我们的消费者可能是一个 坏主意。
我看不到它。如果你能解释为什么你认为这是一个坏主意，可能会有讨论。
看到我的意见下面的其他答案。如果数据库ID使用自然键，我的主要观点是系统和可能的安全问题的耦合。 – tjg184 2012-04-18 13:16:50
1）如果数据库是一个SSN，这可能是一个问题。但是呢？还是我们在讨论theoritically？2）关于耦合：如果你改变数据库，数据不会被丢弃。你的模式会被迁移到新的数据库。所以你担心什么？ – Jim 2012-04-18 13:27:18
1）我们在理论上谈论。 2）是的，架构可能会改变，但是如果架构和数据库独立发展，这将是一件好事。即使从非理论的角度来看，这是相当普遍的，它们的建模方式不同。数据库的规范化与实际模式不同。感谢您的评论。 – tjg184 2012-04-18 13:31:09
yipes - 感觉就像1和2基本一样。还有3 - 当你'定义'是什么使比赛 - 这将几乎肯定是密钥的ID ..（或丑陋 - 找到备用钥匙的一切） – Randy 2012-04-18 12:51:00