REST and HTML - purity vs practicality?

98 views
Skip to first unread message

Gabor

unread,
Oct 11, 2012, 7:25:01 PM10/11/12
to api-...@googlegroups.com
Hi,

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?

Thanks,

Gabor

Steve Klabnik

unread,
Oct 11, 2012, 7:29:01 PM10/11/12
to api-...@googlegroups.com

Michael Peterman

unread,
Oct 13, 2012, 1:22:08 AM10/13/12
to api-...@googlegroups.com
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:
http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post
Reply all
Reply to author
Forward
0 new messages