[Grok-dev] Re: HTTP PUT and HTTP DELETE security support
Martijn Faassen
faassen at startifact.com
Thu May 17 18:49:25 EDT 2007
Oliver Oli wrote:
>> The Ruby on Rails talk discusses higher level systems to make an
>> application get standard REST behavior. The pattern tends to be (also
>> gleaned from the Atom Publishing Protocol that I was pointed to):
>>
>> GET on a container: get list of items in container (in XML, JSON, etc)
>> GET on container item: get container item data
>> POST on a container: create new object
>> PUT on container item: overwrite container item data
>> DELETE on container item: delete container item
>
> A PUT can also be a create operation with a given resource name. A
> POST request should return the location (url) of the created resource.
Right, this is something you can choose to do when building a REST
application, though it is by no means required. I've been examining the
Atom Publishing Protocol, and they only create resources using POST, and
never with PUT. I got the impression the same applied to the RoR
implementation, but perhaps I'm mistaken.
The advantage of using POST for creation is that there is no URL
construction on the client side, something that is frowned on by at
least some REST advocates as they advocate URLs should be opaque to the
client applications (you should be able to click on a link, but you
should never have to take a link apart to construct a new link, with the
exception of relative link construction). With PUT you'd break this
principle, unless you have to do a request first to determine the PUT
URL to use.
What POST should return is also different in different implementations
too, I think. In the Atom Publishing Protocol, the result of POST should
be a representation of the newly created item along with a Location and
possibly a Content-Location header with the URL of the newly created
resource. The name of the resource is indicated with a 'Slug' header in
the POST request, though the system can choose to ignore this or
transform it. (In case you're wondering, it's called Slug as that's
apparently a newspaper term for labeling things)
I'm pretty happy with mining the Atom Publishing Protocol for a lot for
these concrete REST design patterns, as it seems well thought out and
should get quite a bit of traction in time. What you describe is
certainly also a way to do REST (is this how Rails does it?). With Grok
we should promote one, though perhaps making it still possible to
implement the other.
Anyway, just to make clear that what you describe isn't "official" REST,
just a way to do it, and what I've been describing is another.
Regards,
Martijn
More information about the Grok-dev
mailing list