It could be argued that a JDBC connection and a SQL statement did the same around database information (i.e. the connection URI) its not quite as clean as the web approach, but its still a similar concept.
All I'm getting at is that having GUID as the differentiator for REST probably isn't the best marketing exercise as other approaches (some good, most bad) have had a similar concept. Because the Web uses DNS to do the mapping from URI to physical end-point then lots of systems that include a centralised mapping could also lay claim to the same approach. One bit of course about the web approach to URIs that means it isn't a strict GUID is that multiple URIs can refer to the same resource (e.g. Amazon has a bazillion different URIs that link to a specific book). So it might be more correct to say that every datasource has _at least one_ URI. Steve On 23/07/07, Mark Baker <[EMAIL PROTECTED]> wrote:
On 7/22/07, Steve Jones <[EMAIL PROTECTED]<jones.steveg%40gmail.com>> wrote: > Databases would be an equivalent (but not true GUID), Table + Primary > Key. But "true" GUID systems tend to be (IMO) pretty dreadful and > inhouse solutions where every object as a GUID and this is then fired > around and used as a reference point (often via some horrific central > server were you pass the GUID and it returns the object. Your mention of of a central server suggests that identifiers, while assignable in a decentralized fashion (via GUIDs and their low probability of collision), couldn't be dereferenced (turned into data) in the same way. The Web absolutely nailed that by defining a default mapping between URI schemes and application protocols. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca Coactus; Web-inspired integration strategies http://www.coactus.com
