REST and HTML - purity vs practicality?

Showing 1-3 of 3 messages
REST and HTML - purity vs practicality? Gabor 10/11/12 4:25 PM

I'm designing the API of a new web service that I'd like to be as much RESTful as possible. Existing web sites will switch to using this new service soon. I wonder what is your recommendation on using (or not) PUT and DELETE in the API knowing that HTML forms support only GET and POST. Obviously, it would be the easiest for site owners to simply repoint their forms to the new service without having to change the way these forms send their data - i.e. GET or POST. I know that it is possible to send form data using e.g. PUT, too, by the use of Javascript (libraries), I'm just concerned on how much effort it would mean for site owners and ultimately if they're willing to do it.

What is your suggestion: purity vs practicality?


Re: [api-craft] REST and HTML - purity vs practicality? Steve Klabnik 10/11/12 4:29 PM
Re: [api-craft] REST and HTML - purity vs practicality? Michael Peterman 10/12/12 10:22 PM
The important take aways like 'avoid tunneling everything over POST' and 'don't use POST where it doesn't make sense' are there for the pure RESTful API but when you have different real world requirements I think it's most important to solve those first with an understanding of what you are giving up.  Some things that will go away are caching - you can't cache a POST or GET with query params so some of the fancy web-scale badassery won't help you.

More important than being RESTful is knowing your problem space and solving it.  If you have problems requiring RESTful solutions then I would start with what will work for your customers and help them migrate to a more RESTful solution as long as the interim will hold up.

On Thursday, October 11, 2012 4:29:11 PM UTC-7, Steve Klabnik wrote: