Comments on: Payload Formats http://www.subbu.org/blog/2008/10/payload-formats HTTP, REST and some Cycling Mon, 15 Mar 2010 08:14:09 +0000 http://wordpress.org/?v=2.8.4 hourly 1 By: subbu http://www.subbu.org/blog/2008/10/payload-formats/comment-page-1#comment-5670 subbu Thu, 09 Oct 2008 22:42:37 +0000 http://www.subbu.org/?p=426#comment-5670 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). 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).

]]> By: Bill de hÓra http://www.subbu.org/blog/2008/10/payload-formats/comment-page-1#comment-5378 Bill de hÓra Tue, 07 Oct 2008 20:36:07 +0000 http://www.subbu.org/?p=426#comment-5378 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. 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.

]]> By: Bill Burke http://www.subbu.org/blog/2008/10/payload-formats/comment-page-1#comment-5288 Bill Burke Tue, 07 Oct 2008 04:58:32 +0000 http://www.subbu.org/?p=426#comment-5288 <blockquote>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.</blockquote> 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.

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.

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.

]]> By: subbu http://www.subbu.org/blog/2008/10/payload-formats/comment-page-1#comment-5274 subbu Tue, 07 Oct 2008 03:19:40 +0000 http://www.subbu.org/?p=426#comment-5274 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. 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.

]]> By: Bill Burke http://www.subbu.org/blog/2008/10/payload-formats/comment-page-1#comment-5247 Bill Burke Mon, 06 Oct 2008 23:30:27 +0000 http://www.subbu.org/?p=426#comment-5247 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? 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?

]]> By: subbu http://www.subbu.org/blog/2008/10/payload-formats/comment-page-1#comment-5241 subbu Mon, 06 Oct 2008 22:34:37 +0000 http://www.subbu.org/?p=426#comment-5241 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. 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.

]]> By: Bill Burke http://www.subbu.org/blog/2008/10/payload-formats/comment-page-1#comment-5237 Bill Burke Mon, 06 Oct 2008 22:22:57 +0000 http://www.subbu.org/?p=426#comment-5237 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? 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?

]]>