On 13 December 2011 17:26, Robert Collins <robe...@robertcollins.net> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
