Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The reason behind the half-REST design pattern

stereolambda.wordpress.com

Post reply on HN
Print view View original

11–19 of 19 posts

Re: The reason behind the half-REST design pattern

#11

Post by brg »

nzmsv wrote: post #9
brg wrote: post #5

If someone more schooled in web design wouldn't mind answering, what problems arise of by using the GET add-contact api as described in the post? What is the benefit of using xml in the body of a PUT or POST verb vs the headers?

From RFC2616 9.1.1: ...the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. Why? GET should mean simply getting the page. Not doing so runs the risk of: - Bookmarks breaking (what if someone bookmarks the add-contact link?) - Google deleting everything because it followed the links (there is an example of this on The Daily WTF) -…

Thank you for the explanation.

In the example, the add-contact URI was dynamically generated so the deletion from following a url and and bookmark breaking did not seem especially pertinent.

But your explanation made a lot of points clear. One maintains the integrity of the call by placing parameters in the body. Avoiding proxy and caching issues inherit in using GET, as well as avoiding xss, makes immediate sense.

Re: The reason behind the half-REST design pattern

#12

Post by WALoeIII »

techiferous wrote: post #10
wycats wrote: post #7

Earlier quoted context omitted.

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.

Re: The reason behind the half-REST design pattern

#13

Post by WALoeIII »

pak wrote: post #8
techiferous wrote: post #4

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

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 toolcha…

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.

Re: The reason behind the half-REST design pattern

#14

Post by fnid2 »

nzmsv wrote: post #3

Using GET to delete is just asking to have a search crawler wipe your entire site. Not only is this not RESTful, it violates the RFC.

Not requiring a username and password to delete is just asking to have your entire database deleted by a click happy anonymous web browser.

"Ooo... look! I can delete whatever!... Okay..." click click click click...

Re: The reason behind the half-REST design pattern

#15

Post by fnid2 »

udfalkso wrote: post #2

3. Very few people even know that "PUT" and "DELETE" exist.

4. Four CRUD operations are insufficient for even modestly complex applications. Many REST-like api's include the type of operation to perform in the request, but this is against the rigid structure of the REST interface.

Re: The reason behind the half-REST design pattern

#16

Post by nzmsv »

brg wrote: post #11
nzmsv wrote: post #9

Earlier quoted context omitted.

From RFC2616 9.1.1: ...the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. Why? GET should mean simply getting the page. Not doing so runs the risk of: - Bookmarks breaking (what if someone bookmarks the add-contact link?) - Google deleting everything because it followed the links (there is an example of this on The Daily WTF) -…

Thank you for the explanation. In the example, the add-contact URI was dynamically generated so the deletion from following a url and and bookmark breaking did not seem especially pertinent. But your explanation made a lot of points clear. One maintains the integrity of the call by placing parameters in the body. Avoiding proxy and caching issues inherit in using GET, as well as avoiding xss, makes immediate sense.

There can be workarounds, but using something that's not broken in the first place is better. Every one of those issues comes from other software expecting the spec (RFC) to be followed where it's not.

Another thing I remembered after I posted. There is no universally agreed upon maximum query string length, so passing parameters in GET is web server dependent.

Re: The reason behind the half-REST design pattern

#17

Post by pak »

WALoeIII wrote: post #13
pak wrote: post #8

Earlier quoted context omitted.

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 toolcha…

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...

Re: The reason behind the half-REST design pattern

#18

Post by nzmsv »

fnid2 wrote: post #14
nzmsv wrote: post #3

Using GET to delete is just asking to have a search crawler wipe your entire site. Not only is this not RESTful, it violates the RFC.

Not requiring a username and password to delete is just asking to have your entire database deleted by a click happy anonymous web browser. "Ooo... look! I can delete whatever!... Okay..." click click click click...

...and that's why I shouldn't post at 2am :)

Re: The reason behind the half-REST design pattern

#19

Post by william-shulman »

brg wrote: post #5

If someone more schooled in web design wouldn't mind answering, what problems arise of by using the GET add-contact api as described in the post? What is the benefit of using xml in the body of a PUT or POST verb vs the headers?

I agree with the other reasons posted. One more reason is one of expressiveness. When you have a "flat" simple form, it is easy to serialize as name/value pairs and send to the server in that fashion. However, when a form is more complex, with nested structure or with variable-length lists of data, it can be very difficult to come up with a serialization scheme that fits the name/value pair model. Often you end up creating your own mini language. If, however, you use a JSON object or XML node as your payload, you are free to transmit data of arbitrary complexity rather easily. So in cases where the data you want to POST/PUT is not flat, you will have much more expressive power encoding your data in JSON or XML and posting it in the request body.
Post reply on HN