在面向公众的数据集成Web服务中使用GUID作为id

时间:2011-06-02 14:06:09

标签: wcf web-services soap guid

要将问题放入某个上下文,公开Web服务的系统在内部使用GUID作为所有实体的标识符。

在这种情况下,在设计面向公众的数据集成Web服务(主要用于将数据从系统导入或导出到其他外部系统)时,您认为在界面中使用内部标识符的优缺点是什么?服务?

使用这样的解决方案,Web服务的导出方法将返回用GUID标识的dto,导入方法将接受类似的dto - 我假设外部系统将负责为新实体生成新的GUID。

这种方法可能面临的潜在问题是什么?

系统和Web服务的技术堆栈是.NET / WCF / SOAP

1 个答案:

答案 0 :(得分:2)

首先,让我们看看更通用的“如何设置公共API”问题,我的第一个练习是确定服务使用者需要哪些信息。我还查看并查看对象模型中是否存在公司特定的命名。然后,我创建一个服务模型(数据契约,如果你想要特定于WCF),它匹配我想要显示消费者的视图。这包括唯一键,其通常是SKU字符串(人类可读键)而不是GUID / int(实际派生主键),因为SKU是公共的,而存储在数据库中的方法则不是。因此,一般情况下,如果这是GUID,我不会公开这些主键概念。

现在谈到“你看到这种方法存在问题”的问题。我将重点关注更一般的概念,以便您做出更明智的决定,因为没有100%正确/错误的答案。

只要这是机器到机器并且GUID的使用是两个系统都知道的东西,我认为没有什么特别可怕的这种方法。如果这个最终用于人类可读的系统,其中GUID必须与之交互,那么你就有问题。

系统的一个潜在问题是将您自己的主键信息暴露给客户或客户端系统,而这些客户或客户端系统无需了解此详细程度。如果这实际上是“半公开”的,并且选择了供应商列表,则“风险”可能会更低。这是我看到的主要问题。

有人可能会争论GUID(128位)与较小标识符的权重,但这是一个虚假的答案,IMO,因为网络延迟超过了发送几个字节作为请求参数的重量。