Hacker News Reader

Comment by techiferous | Hacker News Reader

I think Ruby on Rails default scaffolding actions and routing have influenced the popularity of the half-REST design.

Rails default scaffolding and routing absolutely do use the full REST design, supporting both PUT and DELETE as well as inbound XML and JSON payloads

Sorry. I thought Rails had to make compromises, like faking PUT.

It fakes the PUT to help out browsers. If you pass in a _method paramater it overrides the actual HTTP verb, but this is actually done in middleware above Rails, the controller sees it as PUT.

That's giving Rails too much credit. I would say the friction of configuring Apache to handle PUT, the lack of support on shared hosting to do this, and the scarcity of PHP tutorials/interest on the subject is more contributory to half-REST implentations.

I myself have been guilty of this. At the end of the day, supporting PUT at expense to ease of use by the API consumer (and effort expended to support their toolchains and SDKs, most of which need extra twiddling to do PUT and DELETE) is just not preferable to getting something working... REST philosophies be damned.

What kind of configuration do you need to do to 'enable' PUT and DELETE? In my experience with 1.3, 2.0 and 2.2 it was always proxied correctly. I am using primarily nginx these days which also proxies the HTTP method without any special configuration.

If you're using mod_php, you have to configure a script handler for PUT requests, and then read from stdin in PHP instead of using the superglobals. Is it hard? Not really, but it's not as easy as using $_POST. Here's a tutorial for anybody interested:

http://www.phpbuilder.com/manual/en/features.file-upload.put...

Reply on news.ycombinator.com