Hi Rob,
On Jan 14, 2008, at 9:50 AM, Rob Heittman wrote:
2.) Send a default entity body so the request goes through.
I think this is the way to go, honestly, even if it lacks the purity
Rhett is looking for.
My interpretation of the spec is that an entity is required for a PUT
I always thought so, but couldn't find a clear citation thereof,
which surprises me greatly. This kind of contravenes one of my core
understanding about what "existence" means for a resource. If
anyone is in conversational contact with any of the HTTP/1.1
authors, I'd be academically interested in their intent on this point!
In reality, I think the issue is that lots of implementors and
implementations have interpreted it the same way as Restlet, so for
all intents and purposes it's probably a bad idea to introduce an
API that relies on PUT of empty entities.
This is part of what I was curious about, since it wasn't 100% clear
to me from the HTTP spec. As I mentioned before, I know of at least
one API which uses a PUT with no entity ( Amazon S3: http://docs.amazonwebservices.com/AmazonS3/2006-03-01/RESTBucketPUT.html
). If the generally agreed interpretation of HTTP is that this is
prohibited, I'll go along with that.
Rhett, I looked back at some of our projects using this design and
found that in all cases the link attributes are /important./ So
maybe if you define the entity body as containing a list of link
attributes (which may be empty for now; <link-attributes/>) you may
find that instead of being an ad hoc workaround, this is a good
forward-looking step for future evolution of your solution. Unless
your understanding of the problem domain indicates that there will
never be any attributes associated with such a linkage.
Yeah, that's my experience too, in general. This link model has been
around for a while and we've never added attributes to it (so I
thought I could skip the entity), but that still could change.
Thanks again for your input,
Rhett
