Using GUIDs as an identifier in a public data integration web service

Question

To put the question in some context, the system that displays the web service uses internal GUIDs as identifiers for all objects.

In this case, when developing a web-based data integration service focused on the public (mainly used to import or export data from the system to other external systems), what would be the advantages and disadvantages of using internal identifiers in the service interface?

With this solution, the web service export methods will return the dto identified with the GUID, and the import methods will accept the same dto - I assume that the external system will be responsible for creating new GUIDs for the new objects.

What are the potential problems you might encounter with this approach?

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

Answer 1

First, let's look at a more general question about how to set up an open API, my first exercise determines what information a service consumer needs. I also look and see if there is any company name in the object model. Then I create a service model (data contract, if you want WCF to be defined) that matches the view I want to show to the consumer. This includes a unique key, which is most often a SKU string (human readable key) than a GUID / int (actual primary key), since the SKU is publicly available and the storage medium in the database is not. Thus, in general, I would not disclose these concepts of the primary key, if that is what a GUID is.

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

While this is machine-to-machine, and using a GUID is something that both systems are aware of, I don’t see anything particularly terrible in this approach. If this final value refers to a human-readable system that needs to interact with a GUID, then you have a problem.

One potential problem with the system is providing your own primary key information to client or client systems that do not need to understand this level of detail. If it is actually “semi-public” with a select list of suppliers, the “risk” may be less. This is the main problem that I see.

It can be argued that the weight of the GUID (128 bits) is compared to a smaller identifier, but this is a fictitious IMO response, since network latency is more than outweighs sending a few more bytes as a request parameter.