Comments on: REST design question #1: identification http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/ Open information and technology. Wed, 01 Sep 2010 22:51:00 +0000 hourly 1 http://wordpress.com/ By: Mark http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-85 Mark Thu, 24 Feb 2005 02:23:41 +0000 /?p=19#comment-85 PROBLEM: You cannot remember the source of the data you've just retrieved over an ambiguous duration or disposition through time. SOLUTION{?}: Attribute an external identifier (the information may not need to care where its from after, you do.) I would elect: www.example.org.airports.ca.cyow.xml or allow embedded paths: 'www.example.org/airports/ca/cyow.xml' PROBLEM: You cannot remember the source of the data you’ve just retrieved over an ambiguous duration or disposition through time.

SOLUTION{?}: Attribute an external identifier (the information may not need to care where its from after, you do.) I would elect: http://www.example.org.airports.ca.cyow.xml
or allow embedded paths: ‘www.example.org/airports/ca/cyow.xml’

]]> By: Bo http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-81 Bo Tue, 22 Feb 2005 23:05:20 +0000 /?p=19#comment-81 Your intial assumptions are wrong. Identifiers, in the business sense that you mean, have nothing to do with URLs. Identifiers should be GUIDs and should never, ever change. URLs are not identifiers and trying to use them as such is silly. It's common in many systems for a single resource to be located by several URLs and it's also common for the business entity represented by a URL to change over time (eg http://www.weather.com/nyc results to a new business entity every 20 minutes). You're not downloading a resource when you GET a URL, you're downloading a representation of a resource. The representation of the resource should contain zero information about its URL (unless that makes sense for the RSS, for example RSS documents) but it should contain an identifer to prevent the need for conversational state. Your intial assumptions are wrong. Identifiers, in the business sense that you mean, have nothing to do with URLs. Identifiers should be GUIDs and should never, ever change. URLs are not identifiers and trying to use them as such is silly. It’s common in many systems for a single resource to be located by several URLs and it’s also common for the business entity represented by a URL to change over time (eg http://www.weather.com/nyc results to a new business entity every 20 minutes). You’re not downloading a resource when you GET a URL, you’re downloading a representation of a resource. The representation of the resource should contain zero information about its URL (unless that makes sense for the RSS, for example RSS documents) but it should contain an identifer to prevent the need for conversational state.

]]> By: Ryan Tomayko http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-80 Ryan Tomayko Tue, 22 Feb 2005 21:41:17 +0000 /?p=19#comment-80 It may be interesting to note that Atom accepted <code><link rel="self"></code> for identifying the location of a feed instead of <code>xml:base</code>. See <a href="http://www.intertwingly.net/wiki/pie/PaceFeedLink" rel="nofollow">PaceFeedLink</a> and <a href="http://www.google.com/search?hl=en&lr=&safe=off&q=+site:www.imc.org+PaceFeedLink+xml:base" rel="nofollow">Discussion</a> on atom-syntax mailing list. This is great stuff, btw, David. It may be interesting to note that Atom accepted <link rel="self"> for identifying the location of a feed instead of xml:base.

See PaceFeedLink and Discussion on atom-syntax mailing list.

This is great stuff, btw, David.

]]> By: Danny http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-78 Danny Thu, 17 Feb 2005 09:17:22 +0000 /?p=19#comment-78 I'm not 100% sure about RESTafarians considering identification and location one and the same thing - surely resources are identified (via URIs), representations are located (via HTTP). The question of where the document identifier should go is spawned by your creating a new resource, albeit with the same representation as the original. A possible solution might be to wrap the content of the document to identify the resource which it represents, i.e. <rdf:Description rdf:about="http://www.example.org/airports/ca/cyow.xml"> I’m not 100% sure about RESTafarians considering identification and location one and the same thing – surely resources are identified (via URIs), representations are located (via HTTP).
The question of where the document identifier should go is spawned by your creating a new resource, albeit with the same representation as the original. A possible solution might be to wrap the content of the document to identify the resource which it represents, i.e.

<rdf:Description rdf:about=”http://www.example.org/airports/ca/cyow.xml”>

]]> By: Sjoerd Visscher http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-77 Sjoerd Visscher Wed, 16 Feb 2005 11:14:19 +0000 /?p=19#comment-77 The default base URI of the root element when there is not xml:base attribute is the base URI of the document, i.e. the URI used to retrieve the document. So you're just asserting what is already the default. Even when you don't need a document identifier it seems good practice, as it makes your data location independent. The default base URI of the root element when there is not xml:base attribute is the base URI of the document, i.e. the URI used to retrieve the document. So you’re just asserting what is already the default.

Even when you don’t need a document identifier it seems good practice, as it makes your data location independent.

]]> By: Mark Baker http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-76 Mark Baker Wed, 16 Feb 2005 05:10:06 +0000 /?p=19#comment-76 xml:base has, on occasion, the same value as the URL from which the document was retrieved, but that's accidental. Consider that it makes no sense to have a base URI that ends with anything other than "/", which most URLs do not do. rdf:about is the closest thing to what David's looking for AFAICT. Full response forthcoming on my weblog ... xml:base has, on occasion, the same value as the URL from which the document was retrieved, but that’s accidental. Consider that it makes no sense to have a base URI that ends with anything other than “/”, which most URLs do not do. rdf:about is the closest thing to what David’s looking for AFAICT.

Full response forthcoming on my weblog …

]]> By: Sjoerd Visscher http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-75 Sjoerd Visscher Tue, 15 Feb 2005 17:57:19 +0000 /?p=19#comment-75 xml:base isn't just a cute hack to set the base URI. From the very beginning of HTML [1] the base href is meant to provide the original URI of the document, to be used when the document is read out of context. XInclude extends this practice by providing with xml:base the url of the originating document. So I'd expect that xml:base would usually contain a resolvable URI of a document, and not a URI like http://www.example.org/airports/ca/ [1] http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationOfHtmlHyperlinks xml:base isn’t just a cute hack to set the base URI. From the very beginning of HTML [1] the base href is meant to provide the original URI of the document, to be used when the document is read out of context. XInclude extends this practice by providing with xml:base the url of the originating document.

So I’d expect that xml:base would usually contain a resolvable URI of a document, and not a URI like http://www.example.org/airports/ca/

[1] http://w3future.com/weblog/2005/01/13.xml#stillBugsInTheImplementationOfHtmlHyperlinks

]]> By: Norman Walsh http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-74 Norman Walsh Tue, 15 Feb 2005 16:37:40 +0000 /?p=19#comment-74 Resolving cyyz.xml against a base URI of http://www.example.org/airports/ca/cyow.xml will result in http://www.example.org/airports/ca/cyyz.xml. That looks like a reasonable use of xml:base to me, though it seems like a slight extension. I'd have expected the xml:base to be http://www.example.org/airports/ca/ (the trailing slash is significant) but maybe that's just narrow-minded of me. Resolving cyyz.xml against a base URI of http://www.example.org/airports/ca/cyow.xml will result in http://www.example.org/airports/ca/cyyz.xml. That looks like a reasonable use of xml:base to me, though it seems like a slight extension. I’d have expected the xml:base to be http://www.example.org/airports/ca/ (the trailing slash is significant) but maybe that’s just narrow-minded of me.

]]> By: Bob DuCharme http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-73 Bob DuCharme Tue, 15 Feb 2005 14:13:32 +0000 /?p=19#comment-73 XLink processors? What XLink processors? XLink processors? What XLink processors?

]]> By: Sjoerd Visscher http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-72 Sjoerd Visscher Tue, 15 Feb 2005 09:32:03 +0000 /?p=19#comment-72 I think this is exactly what xml:base is for. IMHO tools (like browsers) that allow XML documents to be retrieved from the web and stored somewhere else should automatically add an xml:base attribute. XLink tools are either not xml:base aware or they will resolve the links correctly. I don't think you'll ever get cyow.xmlcyyz.xml. Applications that are compatible with DOM Level 3 or with the XML Information Set should give you the base URI for every node. I think this is exactly what xml:base is for. IMHO tools (like browsers) that allow XML documents to be retrieved from the web and stored somewhere else should automatically add an xml:base attribute.

XLink tools are either not xml:base aware or they will resolve the links correctly. I don’t think you’ll ever get cyow.xmlcyyz.xml.

Applications that are compatible with DOM Level 3 or with the XML Information Set should give you the base URI for every node.

]]> By: AsynchronousBlog http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-71 AsynchronousBlog Tue, 15 Feb 2005 04:28:17 +0000 /?p=19#comment-71 <strong>Re: REST Design Questions</strong> Dave Megginson has posted some questions about his understanding of REST. First off, please do look beyond the "there are only 4 [HTTP] verbs" aspect of REST. "Hypermedia as the engine of application state" is hand-in-hand with Constrained Interfac... Re: REST Design Questions
Dave Megginson has posted some questions about his understanding of REST. First off, please do look beyond the “there are only 4 [HTTP] verbs” aspect of REST. “Hypermedia as the engine of application state” is hand-in-hand with Constrained Interfac…

]]> By: Quoderat » REST design question #3: meaning of a link http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-79 Quoderat » REST design question #3: meaning of a link Wed, 30 Nov -0001 00:00:00 +0000 /?p=19#comment-79 [...] is the third in a series of REST design questions. The first design question asked about <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/14/rest-design-question-1-identification/" rel="nofollow">keeping track of location and identification infor [...] [...] is the third in a series of REST design questions. The first design question asked about keeping track of location and identification infor [...]

]]> By: Quoderat » REST design question #4: how much normalization? http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-82 Quoderat » REST design question #4: how much normalization? Wed, 30 Nov -0001 00:00:00 +0000 /?p=19#comment-82 [...] still knows where to look for more complete information. It can also use the link URLs as <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/14/rest-design-question-1-identification/" rel="nofollow">identifiers</a> for disambiguating people, compani [...] [...] still knows where to look for more complete information. It can also use the link URLs as identifiers for disambiguating people, compani [...]

]]> By: Quoderat » REST design question #5: the “C” word (content) http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-83 Quoderat » REST design question #5: the “C” word (content) Wed, 30 Nov -0001 00:00:00 +0000 /?p=19#comment-83 [...] ons has danced around the edge of the content problem dipping in its toes with issues like <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/14/rest-design-question-1-identification/" rel="nofollow">identification</a> and linking, but now that the d [...] [...] ons has danced around the edge of the content problem dipping in its toes with issues like identification and linking, but now that the d [...]

]]> By: Quoderat » REST design question #5: the “C” word (content) http://quoderat.megginson.com/2005/02/14/rest-design-question-1-identification/#comment-84 Quoderat » REST design question #5: the “C” word (content) Wed, 30 Nov -0001 00:00:00 +0000 /?p=19#comment-84 [...] ons has danced around the edge of the content problem dipping in its toes with issues like <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/14/rest-design-question-1-identification/" rel="nofollow">identification</a> and linking, but now that the d [...] [...] ons has danced around the edge of the content problem dipping in its toes with issues like identification and linking, but now that the d [...]

]]>