[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

link types

I am getting lost in what <link> is and isn't for.  So, I figured I would try a different tact.  Suppose we add two attributes: @type and @method.  Here's how it would work:
 
<link type="application/x.atom+xml" method="PUT">URI</link>
 
The possible values of @method are PUT, POST, DELETE, and GET.  If the attribute is missing, the default value is GET.  Regardless of the value, all URIs indicated this way support GET.  Now, here's how each would be used:
 
1) From the POV of an editor, your tool will look for either PUT or POST.  PUT indicates that the associated URI can be used to HTTP GET the entry, then HTTP PUT it back again.  POST indicates that the associated URI can be used to HTTP GET the entry, then HTTP POST it back again.  DELETE indicates that the associated URI can be used to HTTP DELETE the entry.
 
2) From the point of view of the reader, your tool will look for GET.  GET indicates that the associated URI can be used to GET the entry.  Now, obviously this won't have much value as you already have the entry in the feed.  However, @type could indicate other mime types.  For instance, if your browser wants (x)html, it may look for:
 
<link type="application/x.xhtml+xml">URI</link>
 
A single entry may make itself available in multiple formats (SVG, PDF, plaintext, etc), each of which would be indicated by a different @type value (optionally followed by @method="GET").
 
A couple notes:
 
1) For each <link>, the value of URI may be the same or different, depending on the situation.  For instance, in a blog system, the PUT, POST, and DELETE methods may have the same URI, but a different one from the GET method.  For a wiki, it's possible that all four methods share the same URI.
 
2) Because the same URI could be used, we get into the realm of content negotiation.  However, it's not an issue here because the @type value already tells you what "Accepts" header should be.
 
3) There is no fixed set of <link> elements required.  A given implementation may only provide the following links:
 
<link type="application/x.atom+xml" method="PUT">URI1</link>
<link type="application/x.atom+xml">URI2</link>
<link type="application/x.xhtml+xml">URI2</link>
 
while another may choose to provide
 
<link type="application/x.atom+xml" method="POST">URI1</link>
<link type="application/x.atom+xml method="DELETE">URI2</link>
<link type="application/x.xhtml+xml">URI2</link>
 
4) Suppose you use Textile to write your entries (or WikiML for wikis).  If you have a list of links like the first example in #3 above, the GET on URI1 would return a version of the <entry> where the <content> contained Textile, while a GET on URI2 would return a version of the <entry> that contained xhtml (or whatever).
 
5) This approach does not solve the introspection necessary to create an entry.  It only deals with an entry that already exists.
 
6) I know there is some contention about how POST should be used.  People may not feel comfortable with GETting and POSTing to the same URI.  An alternative approach might go as follows... You have an entry with the following link:
 
<link type="application/x.atom+xml" method="POST">URI1</link>
 
You GET URI1.  This returns an <entry> that you will edit.  It also contains the following link:
 
<link type="application/x.atom+xml" method="POST">URI2</link>
 
You post the change back to URI2, which is likely a more generic URI (that uses the <id> to disambiguate entries).  This "sleight of hand" may make RESTifarians more confortable.  On the other hand, this could be too complicated.  Personally, I'm still sitting on the fence on how POST should and should not be used.  (note: it would also be possible to do PUT this way, but I'm not sure that there's any value in it.)
 
7) While it is unlikely that a given entry would provide for both POST and PUT, it is possible.  For instance, since a POST operation may automatically update certain elements (dates, etc), there would be no need to make them available for editing.  On the other hand, if the additional editability is absolutely necessary, the PUT variant may contain all available elements.
 
8) The issue of URI construction potentially becomes moot, I think... or at least less of an issue.  When the entry is created, you could include a <link> to eplicitly say what you want the URI to be.  Of course, the server may disagree and assign its own URI.  But now we are dealing a value in a link element, not the URI that we are trying to create the entry with.
 
 
I think that's it for now...