Bill Burke says:
For me, the value of Atom haven’t really clicked with me yet. Its just too SOAPy for me. If you look at ATOM, the ATOM protocol, and how people are talking about using it, they’re really using it as an envelope. One of the things that attracted me to REST was that I could focus on the problem at hand and ignore bulky middleware protocols (like SOAP) and lean on HTTP as a rich application protocol.
This is a plausible conclusion when linking is ignored. I find that Atom's linking, and the abstraction of resource collections as feeds the most useful for structuring representations.
However, I do find that the resource metadata specified by Atom is certainly heavy-weight for most data-centric (as opposed to content/feed-centric) applications. In particular, the MUST/SHOULD requirements on the following in Atom are too constraining.
atom:titleatom:authoratom:updated(and the AtomPub cousin app:created)atom:id
How about an Atom-Lite with the above made optional?
As far as AtomPub is concerned, it is nice to profile HTTP for resource collections (aka feeds), but collection is one possible abstraction, and it does not make sense to profile HTTP for every possible resource abstraction. HTTP 1.1 is good enough for me.
{ 4 comments… read them below or add one }
With Multipart there’s no reason you can’t have a Location header in the sub-part. Or again, why not a comma delimited list of URLs? Don’t both of those satisfy your linking requirement?
[Reply]
subbu Reply:
October 6th, 2008 at 3:34 pm
Well, you can use Atom entries/feeds as one of the parts in a multipart message.
I am a bit confused by your reference to the Location header in the reply above, and the Content-Location header in your post. Location is useful only for 201 and most 3xx response codes. I am not sure how this is related to a specific format used for representations. Content-Location has a totally different purpose.
Passing a list of URIs does not satisfy the linking requirement. Link relations (the rel attribute) are needed to describe how the resource/representation at a given URI is related to the referring representation. Plain URIs are more or less useless without a relation.
[Reply]
Why can you not use Location/Content-Location within a multipart response? Specifically in the orders example of the infoq article. Each part could have a Content-Location header describing where the resource is along with a representation of that resource. The Order fulfiller would PUT on the URL provided to change the state to “I’m working on it now”. In this case, we’re providing both the entity and the location of the entity through the multipart format. We don’t need a relationship attribute here as there is only one relationship. In other words, the relationship is implicit, so why describe it? Why force the client (and server) to process an envelope?
[Reply]
subbu Reply:
October 6th, 2008 at 8:19 pm
Bill – Content-Location is meant for telling the clients of direct URIs, if available, for negotiated responses. Please see http://www.subbu.org/blog/2008/10/location-vs-content-location. The usage you are suggesting, viz., PUTting to the Content-Location URI is not specified by HTTP.
I agree that when there is only link whose relationship can be unambiguously determined, the rel attribute is not very useful.
Another good use case for the envelope is to separate the content/data of the resource from the metadata. But I admit that I don’t find that very exciting.
[Reply]
Reading your “On linking” blogs, the envelope seems even less exciting as you may have multiple levels of embedded links within your representation, at least from the example you gave.
BTW, thanks for taking the time for this exchange. I argue to learn, and you have a great blog to learn from.
[Reply]
Don’t agree with the last two, but the first two are often redundant in a non-publishing context.
Sometimes I think we (as in the industry) now know enough to spec a decent envelope format for data – that isn’t MIME.
[Reply]
subbu Reply:
October 9th, 2008 at 3:42 pm
Agree about atom:id for resources, but not convinced about atom:id on collections (feeds). Also not convinced about atom:updated on feeds, and entries that are fetched directly. In those cases, atom:updated duplicates Last-Modified. atom:updated may be useful for entries fetched through a feed, but I would prefer to rely on Last-Modified (and ETag).
[Reply]