在面向公众的数据集成Web服务中将GUID用作ID [英] Use of GUIDs as id in public facing data integration web service

问题描述

为了将问题放在某种上下文中，公开Web服务的系统在内部使用GUID作为所有实体的标识符.

To put the question into some context, the system exposing the web service uses GUIDs internally as identifiers for all entities.

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

In such case, when designing a public facing data integration web service (used mainly for importing or exporting data from the system to other, external systems), what would you consider as pros and cons of using the internal identifiers in the interface of the service?

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

With such solution, the export methods of the web service would return the dto's identified with GUIDs and the import methods would accept similar dto's - I assume the external system would be responsible for generating new GUIDs for new entities.

使用这种方法可能会遇到哪些潜在问题?

What are the potential issues one might face with this approach?

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

The technology stack for the system and web service is .NET / WCF / SOAP

推荐答案

首先，让我们看一下更通用的如何设置公共API"问题，我的第一个练习是确定以下用户的信息需求服务.我还查看对象模型中是否存在公司特定的命名.然后，我创建一个服务模型(如果需要WCF，则为数据合同)，该模型与我要向使用者显示的视图相匹配.这包括一个唯一密钥，它比GUID/int(实际派生的主密钥)多是SKU字符串(人类可读密钥)，因为SKU是公共的，而存储在数据库中的方式则不是.因此，总的来说，如果那是GUID，那么我不会公开这些主要的关键概念.

First, let's look at the more generic "how do I set up a public API" question, my first exercise is determining what information is needed by the consumer of the service. I also look and see if there are is company specific naming in the object model. I then create a service model (data contract, if you want WCF specific) that matches the view I want to show the consumer. This includes a unique key, which is more often a SKU string (human readable key) than a GUID/int (the actual derived primary key), as the SKU is public and the means of storing in the database is not. So, in general, I would not expose these primary key concepts, if that is what the GUID is.

现在的问题是您认为这种方法有问题吗".我将重点介绍更笼统的概念，以便您做出更明智的决定，因为没有100％正确/错误的答案.

Now to the question of "do you see problems with this approach". I will focus on more general concepts so you can make a more informed decision, as there is no 100% right/wrong answer.

只要这是机器对机器，并且两个系统都知道GUID的使用，那么我认为这种方法没有什么特别可怕的.如果最终的解决方案是必须与GUID进行交互的人类可读系统，那么您将遇到问题.

As long as this is machine to machine and the use of the GUID is something both systems are aware of, I see nothing particularly scary about this approach. If this ultimate goes to a human readable system where the GUID has to be interacted with, then you have an issue.

该系统的一个潜在问题是将您自己的主键信息暴露给不必了解此详细程度的客户或客户系统.如果这实际上是带有选定供应商列表的半公开"，则风险"可能会较小.这是我看到的主要问题.

One potential issue with the system is exposing your own primary key information to customer or client systems, who don't have to understand this level of detail. If this is actually "semi-public" with a select list of vendors, the "risk" might be less. This is the primary issue I see.

有人可能会争辩说GUID的权重(128位)与较小的标识符相比，但这是一个虚假的答案，即IMO，因为网络延迟远远超过了发送更多字节作为请求参数的可能性.

One could argue the weight of the GUID (128 bits) versus a smaller identifier, but this is a bogus answer, IMO, as the network latency more than outweighs sending a few more bytes as a request parameter.

这篇关于在面向公众的数据集成Web服务中将GUID用作ID的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！