我们有两个独立的系统通过Web服务进行通信。称他们为前端和后端。许多处理涉及更新后端的列表。例如，前端需要更新特定的人。目前，我们正在设计后端，我们正在决定接口应该是什么。我们需要实际的数据库ID来更新底层数据库，但我们也看到向我们的消费者传播数据库ID的位置可能是个坏主意。
强制客户端（即前端）必须将id发送回Web服务以更新特定实体有哪些替代方案？我们试图避免使用ID的另一个原因是前端通常会保存这些更改以便以后发送。这需要前端将我们的ID保存在他们的系统中，这似乎也是一个坏主意。
我们考虑过以下事项：
1）将数据库ID发送回前端;他们必须将这些发回去处理变更
2）将散列ID（基于数据库ID）发送回前端;他们必须将这些发回去处理变更。
3）不要强制客户端发送ID，而是让它们发送原始实体和新实体并“匹配”到数据库中的实体。他们原来的实体必须匹配我们保存的实体。我们还必须定义我们的实体与其新实体之间的匹配构成。
答案 0 :(得分：3)
前端唯一合理的方法是在某种程度上识别数据库中的人员。
匹配整个实体是不可靠的，并不明显;要将散列ID返回到前端，您需要先从前端接收未散列的ID，或者在ID下执行一些可恢复的“散列”（更像是“加密”），所以无论如何都会有一些人物标识符。
恕我直言，无论是数据库ID还是从中提取ID的某些数据（加密数据库ID）都无关紧要。为什么你认为消费者知道数据库ID会是个坏主意？只要每个人都属于一个消费者，我就不会发现任何问题。
如果人（DB中的对象）与消费者之间存在多对多关系，那么您可以“加密”（广义上）对象ID，以便加密依赖于消费者。例如，在与消费者的通信中，您可以使用DB中的链接ID（对象和消费者之间）条目。
如果向消费者发送ID似乎对您不利，因为消费者可能逐个枚举所有ID，您可以通过使用GUID而不是整数自动递增ID来避免此问题。 / p>
PS：至于你的评论，请考虑使用例如GUID作为对象ID。 ID是数据的一部分，而不是模式的一部分，因此在数据库之间迁移时将保留它。此类ID也不包含敏感信息，因此向消费者（或其他人）透露ID是完全安全的。如果您想阻止使用相同的SSN创建两个不同的人，只需在SSN字段上添加UNIQUE密钥，但不要使用SSN作为ID的一部分，因为这种方法有许多严重的缺点，无法使用揭示身份证号码是最不合适的。
答案 1 :(得分：2)
从我的观点来看，记录的ID不会向任何人传达任何敏感信息 因此，将数据库ID传输到前端（通常）是没有问题的 唯一的问题是数据库一致性问题，但我看不到任何问题 除了性能之外，它还要好得多，因为您不需要在属性上查询数据库来查找数据库ID。
此外，如果您发送id的哈希值，则无法从哈希值中提取id 您必须在数据库中找到与哈希相匹配的ID，这不是很好的IMO
所以：
我们还看到向我们的消费者传播数据库ID的位置可能是一个 馊主意。
我没有看到它。如果你能解释为什么你认为这是一个坏主意，可能会有讨论。