Comments on: Another REST Anti-Pattern http://www.subbu.org/blog/2008/07/another-rest-anti-pattern HTTP, REST and some Cycling Thu, 20 Nov 2008 20:54:06 +0000 http://wordpress.org/?v=2.7-beta3 hourly 1 By: Stephen Waits http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-294 Stephen Waits Sat, 12 Jul 2008 05:42:55 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-294 REST, including the :method => :hacks for browsers not supporting all of the "verbs", has been a huge counterproductive diversion for DHH and many of the Rails folks. Nobody seems capable of taking a step back. If they did, they'd realize that (real) end-users don't give a shit about REST, aside from maybe pretty URLs, which have little to do with it. Granted, because so much work went into it, you pretty much need to get on the bandwagon when doing Rails these days. It'll just make your life easier. And yes, ultimately, that makes web services easier to code. My point is, in the 1.? -> 1.2 timeframe, and even today, there were way bigger fish to fry. Rails people tend to get distracted by shiny things. REST, including the :method => :hacks for browsers not supporting all of the “verbs”, has been a huge counterproductive diversion for DHH and many of the Rails folks.

Nobody seems capable of taking a step back. If they did, they’d realize that (real) end-users don’t give a shit about REST, aside from maybe pretty URLs, which have little to do with it.

Granted, because so much work went into it, you pretty much need to get on the bandwagon when doing Rails these days. It’ll just make your life easier. And yes, ultimately, that makes web services easier to code.

My point is, in the 1.? -> 1.2 timeframe, and even today, there were way bigger fish to fry.

Rails people tend to get distracted by shiny things.

]]> By: Grempe http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-293 Grempe Fri, 11 Jul 2008 23:48:01 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-293 Perhaps we should instead be asking why browsers won't support PUT and DELETE natively? Perhaps we should instead be asking why browsers won’t support PUT and DELETE natively?

]]> By: Subbu Allamaraju http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-292 Subbu Allamaraju Fri, 11 Jul 2008 18:33:03 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-292 I see your point. I see your point.

]]> By: Assaf http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-291 Assaf Fri, 11 Jul 2008 18:11:42 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-291 Check out ActiveResource (also part of Rails). See the verbs? By design Rails accepts all the methods. By design Rails uses these methods when it can. If the world switched over to HTML 5 tomorrow, Rails developers would just run gem update rails. That's because the hack is buried in the framework, but your application code is written around verb semantics. So it deals with the unfortunate incident that is web browsers. It supports clients that can use HTTP methods properly. And it teaches you to develop code around the uniform interface. Check out ActiveResource (also part of Rails). See the verbs?

By design Rails accepts all the methods. By design Rails uses these methods when it can.

If the world switched over to HTML 5 tomorrow, Rails developers would just run gem update rails.

That’s because the hack is buried in the framework, but your application code is written around verb semantics.

So it deals with the unfortunate incident that is web browsers. It supports clients that can use HTTP methods properly. And it teaches you to develop code around the uniform interface.

]]> By: Aristotle Pagaltzis http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-290 Aristotle Pagaltzis Fri, 11 Jul 2008 18:07:20 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-290 I don’t see a problem. POST makes fewer guarantees than PUT or DELETE (to be precise, it makes none), so intermediaries won’t make mistaken assumptions about what conditions hold true after such a request. Sure, by tunnelling other methods over POST, you lose the advantages that the stronger guarantees of those methods confer. But as Roy himself has said, it is well possible to design a perfectly RESTful system with just GET and POST. What you are calling an anti-pattern is just suboptimal design. It is certainly not on equal footing with the mistakes than Stefan listed such as GET with side-effects. I don’t see a problem. POST makes fewer guarantees than PUT or DELETE (to be precise, it makes none), so intermediaries won’t make mistaken assumptions about what conditions hold true after such a request. Sure, by tunnelling other methods over POST, you lose the advantages that the stronger guarantees of those methods confer. But as Roy himself has said, it is well possible to design a perfectly RESTful system with just GET and POST.

What you are calling an anti-pattern is just suboptimal design. It is certainly not on equal footing with the mistakes than Stefan listed such as GET with side-effects.

]]> By: Subbu Allamaraju http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-289 Subbu Allamaraju Fri, 11 Jul 2008 10:40:19 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-289 As commented in my response to Stefan above, if the only intent is to work-around HTML forms limitations, this approach does not make sense. As commented in my response to Stefan above, if the only intent is to work-around HTML forms limitations, this approach does not make sense.

]]> By: Hari http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-288 Hari Fri, 11 Jul 2008 10:32:50 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-288 Same with PUT ! I think its a well understood idea in the Rails community that this is only a pragmatic workaround for limitations the browser in its current form imposes. If you are using ActiveResource or any other Http client library you don't have to do this and could send a put/delete request. Now that you have made a strong remark it will help to know what your recommendations are for performing restful actions from within a browser? Same with PUT !
I think its a well understood idea in the Rails community that this is only a pragmatic workaround for limitations the browser in its current form imposes.
If you are using ActiveResource or any other Http client library you don’t have to do this and could send a put/delete request.

Now that you have made a strong remark it will help to know what your recommendations are for performing restful actions from within a browser?

]]> By: Subbu Allamaraju http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-287 Subbu Allamaraju Fri, 11 Jul 2008 07:21:29 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-287 True, but that is like RPC where the URI or a header includes the verb used by the server application while the client and the network need to treat it as an HTTP POST. This is not very much different from how WS-Transfer wants to do PUTs and DELETEs. I am just questioning the intent of such features. Such approaches can be justified if the intent was to let the same server code handle HTML forms based clients as well as non-forms based clients that can support real PUT and DELETE. That may be true for the GData case. But since GData APIs are hosted by Google itself, I would be surprised if their proxies are not configured to support PUTs and DELETEs. True, but that is like RPC where the URI or a header includes the verb used by the server application while the client and the network need to treat it as an HTTP POST. This is not very much different from how WS-Transfer wants to do PUTs and DELETEs. I am just questioning the intent of such features.

Such approaches can be justified if the intent was to let the same server code handle HTML forms based clients as well as non-forms based clients that can support real PUT and DELETE.

That may be true for the GData case. But since GData APIs are hosted by Google itself, I would be surprised if their proxies are not configured to support PUTs and DELETEs.

]]> By: Daniel Yokomizo http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-286 Daniel Yokomizo Fri, 11 Jul 2008 04:49:33 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-286 So what should a RESTful application, one accessed via browser, do? I'm not talking about the particular example of creating a form for links, but if I have a plain old form to update a resource how should I do it? It would only be an Anti-Pattern if it wasn't used to overcome limitations on HTML. So what should a RESTful application, one accessed via browser, do? I’m not talking about the particular example of creating a form for links, but if I have a plain old form to update a resource how should I do it? It would only be an Anti-Pattern if it wasn’t used to overcome limitations on HTML.

]]> By: Stefan Tilkov http://www.subbu.org/blog/2008/07/another-rest-anti-pattern/comment-page-1#comment-285 Stefan Tilkov Fri, 11 Jul 2008 01:18:07 +0000 http://wp.subbu.org/2008/07/another-rest-anti-pattern/#comment-285 Interesting - I see the problems with this approach (e.g. tricking firewalls into letting something through they'd normally forbid), but I don't agree it's worthless: it lets the server-side code handle DELETEs issued via e.g. curl, wget or some application client in the same way as those issued from a browser. Interesting - I see the problems with this approach (e.g. tricking firewalls into letting something through they’d normally forbid), but I don’t agree it’s worthless: it lets the server-side code handle DELETEs issued via e.g. curl, wget or some application client in the same way as those issued from a browser.

]]>