launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxxx>]

On 13 December 2011 17:26, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> wrote:
> I think the question this raises is 'why not use urls for these
> backend services?' For which we could, but I wouldn't want use to
> confuse issues by using urls that are addressable on our public API,
> unless they truely reflect the same thing. And given that our url
> structure is extremely mutable, that would be a problem, because
> stability is a criteria for soa ids.

Indeed.

I think URLs are a good default today for referring to objects unless
you have a strong reason to do otherwise.  There is code that knows
how to deal with them and perhaps more importantly every person
already has reasonable expectations for how they behave and how they
should be treated.  They would need to remember they're opaque, but
that is true for any string.

Well-chosen URLs will meet the four constraints you gave:

 - no two object ids can be the same unless the same object is being referenced.
 - object ids cannot change (unless some explicit process is
undertaken - e.g. messages to all services to update their references)
 - object ids must be bounded in length: no 4K strings.
 - *only* the service emitting the object needs to be able to
dereference it: there is no 'global' allocation or parsing authority

-- 
Martin