为了将问题置于某种上下文中，公开 Web 服务的系统在内部使用 GUID 作为所有实体的标识符。
在这种情况下，在设计面向公众的数据集成 Web 服务（主要用于将数据从系统导入或导出到其他外部系统）时，您认为在接口中使用内部标识符的优点和缺点是什么？服务？
使用这样的解决方案，Web 服务的导出方法将返回用 GUID 标识的 dto，导入方法将接受类似的 dto - 我假设外部系统将负责为新实体生成新的 GUID。
这种方法可能会面临哪些潜在问题？
系统和Web服务的技术堆栈是.NET / WCF / SOAP
首先，让我们看一下更通用的“如何设置公共 API”问题，我的第一个练习是确定服务的使用者需要哪些信息。我还会查看对象模型中是否有公司特定的命名。然后，我创建一个与我想要向消费者展示的视图相匹配的服务模型（数据契约，如果您特别需要 WCF）。这包括一个唯一键，它通常是 SKU 字符串（人类可读的键）而不是 GUID/int（实际派生的主键），因为 SKU 是公开的，而在数据库中存储的方式不是公开的。因此，一般来说，如果 GUID 就是这样的话，我不会公开这些主要关键概念。
现在的问题是“您认为这种方法有问题吗”。我将重点关注更一般的概念，以便您可以做出更明智的决定，因为没有 100% 正确/错误的答案。
只要这是机器对机器并且两个系统都知道 GUID 的使用，我认为这种方法没有什么特别可怕的。如果这个终极版进入了必须与 GUID 交互的人类可读系统，那么您就会遇到问题。
系统的一个潜在问题是将您自己的主要关键信息暴露给客户或客户端系统，而他们不必了解这一级别的详细信息。如果这实际上是“半公开”的，并且有选定的供应商列表，那么“风险”可能会更小。这是我看到的首要问题。
有人可能会争论 GUID（128 位）的权重与较小的标识符，但在我看来，这是一个虚假的答案，因为网络延迟比发送更多字节作为请求参数更重要。