Having problems with message search?
Keeping in mind that a proliferation of custom media types limits the usability of a system, I tend to lean on the side of URIs when identifying interesting items.
Also, I see using the rel="" value as a way to add metadata to links, not a way to tell servers which representation/resource to return.
mca
http://amundsen.com/blog/
mca
http://amundsen.com/blog/
On Mon, Jul 6, 2009 at 14:27, Sam Johnston <samj@...> wrote:
Well, the “[as is]” isn’t actually part of the RFC.
Right, which is why I said "The way I read the RFC is..."The body of the PUT request is simply a *representation* of the state.
Which brings me to a question I considered asking but didn't. REST talks about representations of resources, where one resource can have multiple representations.
Let's say I have a person (http://example.com/person/123) and instead of transferring the person over HTTP (which is not yet possible) I make available their portrait, fingerprint(s), a scan of their national ID card and some XML demographics. Where I use distinct content types I can simply PUT a given representation and have the server side state updated accordingly.
What's the best practice though when portrait, fingerprint and scan are JPGs? That is, I'm retrieving http://example.com/person/123 with Accept: image/jpeg but it's impossible to tell whether it's the portrait, fingerprint or scan I'm after. Similarly, what if I want the fingerprint in PNG?
I immediately start thinking about putting the content-type and/or link-relation into the URL:
http://example.com/person/123;rel=portrait;type=image/jpeg
Then I start to think about cleaning this up a bit:
http://example.com/person/123/portrait.jpg
But this requires routes/rules and doesn't seem as clean/flexible as it should be.
Sam
Offline 
Send Email