[Grok-dev] Re: HTTP PUT and HTTP DELETE security support

[Martijn Faassen]

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