9 ms·

Rails 4.0: PATCH will replace PUT as the primary HTTP method for updates

195 points by anthony_franco 15y ago

saurik 15y ago
The concern is not whether "my web server" will understand PATCH, but whether the random proxy between my web server and the client will; I'm totally willing to believe it does (1995 is a long time ago, I've certainly used and heard about PATCH, and even more elaborate WebDAV methods like PROPPATCH are used by Subversion without serious issue), but to ask about the web server and ignore the proxies is disappointing.
- aaronblohowiak 15y ago
  _method param is used to override the true http method with the one rails should use for routing, so everything can go over vanilla POST
  - binarysoul 15y ago
    yes this is exactly right, its POST for compatibility reasons, rails puts a special parameter in the form submit to map to PUT (for resourceful routes)
- SystemOut 15y ago
  As I currently work in the K-12 educational software industry this is something I would be extremely sensitive to. The sheer number of creaky, old proxy servers out there that we have to contend with is mind boggling. I'm sure others have to deal with this to but I suspect that the education market is one where people will run into surprises and most likely won't realize what the issue is right away. As the sibling post pointed out there is way to change the http method used but I suspect most people won't do this or know about this and this is a really really hard thing to QA for.
  - tptacek 15y ago
    I have a hard time believing that Rails programmers will use resource routing and not understand _method. It's pretty fundamental to the way the framework works. Are you a Rails dev? If not, just know: for the most part, we're talking about different flavors of HTTP POST.
    - ryanto 15y ago
      At the time of reading your comment it is light gray. I am not sure why people are downvoting you... _method is a pretty important part of the rails routing and solves a lot of the proxy/server problems that people are mentioning. In fact, I would argue that things like put/patch/_method are what make Rails so great. Rails makes a lot of strong opinions (put, whoops no, patch!), but then at then end of the day always gives you a way (_method) to deal with any issues where their opinions may not work in your current architecture. This pattern appears throughout the framework and is one of the reasons I really enjoy Rails.
    - apike 15y ago
      The concern isn't simply that there will be Rails programmers in K-12 that don't know how to override an HTTP method. The concern is that when K-12 users are using Rails 4 apps (that may or may not be K-12 specific) they may fail in bizarre ways that are hard to troubleshoot.
      - lparry 15y ago
        It's not an issue because web browsers only support GET and POST. Rails works around this by including a hidden field "_method" which contains the method the server should treat the request as.
        justincormack 15y ago
        That's not true xmlhttprequest should support all methods but there are some quirks eg see http://www.mnot.net/javascript/xmlhttprequest/ http://www.mnot.net/javascript/xmlhttprequest/ to test though that does not cover PATCH.
mitchellh 15y ago
I don't use Rails anymore, but I did professionally for 3.5 years, so I think that gives me the right to a strong opinion on this, so here we go: Why are they even bothering? Really, who cares about PATCH vs. PUT? If PATCH even has a remote chance of breaking 0.01% of sites, then WHY do it? PUT works fine. I don't care. I don't care either way, actually, since I don't use Rails anymore, just put PATCH in. But my main concern is: Why is this major blog post worthy for Rails? I want to see something like "Rails 4: Damn Simple Websockets" or something to show that Rails is modernizing. I spent some time playing (read: nothing serious) with Lift and Scala, and while I wouldn't use that full time, it is clear to see that Lift has a handful of features that are just amazing for a modern website that Rails completely lacks (ridiculously simple AJAX/websocket stuff, triggering UI elements based on data model changes in the backend, etc.). Anyways, its so early that Rails 4 is still a big unknown, but this is not the PR start I would've liked to see.
- batista 15y ago
  If PATCH even has a remote chance of breaking 0.01% of sites, then WHY do it? PUT works fine. I don't care. Well, this "if it even remotely breaks 0.01%" and "I don't care" attitude is the main reason things get bloated and stop progressing.
  - moe 15y ago
    We seem to have different ideas of progress. To my eye Rails is picking up bloat like there's no tomorrow and happily adopting questionable decisions like the above. Meanwhile fundamental issues remain largely unaddressed. There's still serious performance regressions. The asset pipeline is still sort of a trainwreck. There's still no automation for schema migrations (perhaps hobo fields will finally bring some relief for those who adopt it). They still don't seem to have realized that code generators are a no-go. I see zero efforts towards modernizing the bloated routing and MVC cruft to accomodate modern fat-clients (and imho the "resources"-magic was a terrible idea from the start even for regular apps). The whole thing is still riddled with ungodly amounts of magic that likes to break in unpredictable ways (my pet bug: the monkey-patch to really suppress browser stack-traces in production changes about every 3 months and it's worrying such a bug was deliberately created in first place). I could go on for a while... </rant>
minikomi 15y ago
Interesting to say the least seeing this on the front page lined up with "right" vs "pragmatic".
nfm 15y ago
See also the lengthy GitHub discussions about this issue: https://github.com/rails/rails/issues/348 https://github.com/rails/rails/issues/348 https://github.com/rails/rails/pull/431 https://github.com/rails/rails/pull/431 https://github.com/rails/rails/pull/505 https://github.com/rails/rails/pull/505 https://github.com/rails/rails/pull/5130 https://github.com/rails/rails/pull/5130
kennystone 15y ago
Not the good kind of innovation. Some nerds won an argument about HTTP semantics. Rails used to understand the importance of convention. This just seems silly and meaningless, change just for change.
- homosaur 15y ago
  Maybe it is, maybe it's not, but I don't think moving from technically incorrect to technically correct is change for change's sake. There's benefits to doing things by spec even if they are not immediately obvious. I think what you're saying though is that the downsides are. You may be right on that, but I'm going to withhold judgement until I really figure out what this means.
- deleted 15y ago
  [deleted]
samd 15y ago
Rails never used PUT correctly to begin with. Everybody uses update_attributes which does partial updates. Ideally you wouldn't need to do partial updates and just send the entire resource; your resources shouldn't be so big that that's an issue. It's much simpler than making the front-end decide when to do full versus partial updates and which method to use. Rails can't really do that though, too much legacy code out there, too many people set in their ways. Resorting to PATCH is their only option if they want to use HTTP correctly.
- wccrawford 15y ago
  Thanks, I was just wondering about this. I've never written a REST service in Rails, but when I wrote one (after doing a lot of research), it seemed obvious to me that partial updates are an absolute necessity. I had actually thought to try to use a Rails-based REST service in the future, because I thought it would be quicker than rolling my own again (I had no choice, honest!) but without partial updates, I couldn't use it.
functionform 15y ago
what a pointless change.
monsterix 15y ago
On the contrary, I feel Rails is in an awesome direction now. Here is why: Playing with rails for more than 3 years, and then suddenly something new comes and hits you is obviously going to hurt. Let me start with the Assets Pipeline, and in particular - style & script. Did you feel that it is important to control the no. of bits and bytes going into your css now? Until Sprockets came by, people would drop a load of crap in the public/stylesheets (bloated with properties !importants and all). Continuing this way, is going to affect your app's responsiveness on new landscapes - aka tablets, hand-helds especially if you're thinking about "app-development with non-native approach" in your mind. I mean it's not about syntactic sugar alone. It's about the ability to see what can be removed completely from the code and dried up to give desired result with maximum re-usability. Now I'd credit this to the "direction of rails" which served SASS/SCSS or coffeescript as default. It forced me to think and add programming logic into style. Personally, I like it. Also what fails me, is the classic nodejs vs Rails war. Let me re-word this: It is a classic unfounded flame-war, as described in HN guidelines. Both technologies have a place and are useful for even more mutually-exclusive scenarios. Why compare?, just do you own thing! To sum it up - there is a need to take a step back and consider the idea "you wouldn't bump on something new thing or useful with status quo." I would definitely like to consider PATCH over PUT.
dirtyhand 15y ago
jumped the shark, Rails has
dlitz 15y ago
What it's actually doing is un-breaking HTTP caching and proxying semantics, so that we can meaningfully deploy those caches and proxies in a few years. That should help with scalability, and performance at scale. For example, if PUT is actually implemented properly, then you can implement write-back caching semantics with a general-purpose HTTP proxy. The way that Rails currently abuses PUT, a general-purpose proxy can only implement write-through caching (at best), or it needs to be customized for the specific application in use. Also, it's standardizing the language that developers are using to interact with each other, and reducing the amount of work needed to build interoperable software. As more and more websites turn into web services (even if those services are only consumed by e.g. client-side Javascript), this should result in cost savings and faster time-to-market as more businesses move in that direction. Finally, a lot of web apps are basically just CRUD (create/read/update/delete) apps. The more we standardize the on-the-wire protocols for these routine operations, the more we can push those protocols into application frameworks. This means that, as developers, we can work on things that are actually valuable, rather than coming up with new, site-specific ways of shuffling this data around the network.
- subleq 15y ago
  How is a write-back cache possible in an HTTP proxy? I understand write-through caching for PUT requests (The proxy doesn't have to repeat future identical PUTs because PUT is idempotent), but how does the proxy know what the response to the original PUT request is unless it performs the request against the origin server immediately? Edit: I just noticed that RFC 2616 mandates write-through behavior: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.11 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...
jkahn 15y ago
There is a huge amount of hate on HN against Rails lately. Most of it amounts to the straw man attack of "Rails is bloated and old, Node/insert tiny framework here is where it's at". I code with Rails. With Rails 3.2, I'm more productive than I've ever been. What others call "bloat", I call "features". It is surprisingly good having an out of the box asset pipeline for optimization of JS/CSS. The simplicity with which you can construct and adjust scoped queries with ActiveRecord is astounding. The ease of adding pre-baked authentication and authorization gems is great. Seriously - screw writing a large data-driven web app in a tiny framework. You get so much for free in Rails. Yes, Rails has some issues. It has a long initial load time. Ruby is not the fastest language. My main complaint about Rails at the moment would be that it moves too quickly - not that it moves too slow. If you're writing an app to service millions of users simultaneously (and not charging for it), the speed might be an issue. I haven't found it to be a problem in my company, where we charge money for what we write. And on this change - I'm not fussed either way, but it's certainly good that Rails core mention this on the Rails blog so that Rails developers are aware of it well before 4.0 comes out. And standards compliance is a good enough reason for me.
- ticks 15y ago
  The way I see it, HN has lots of people who jump on and off of bandwagons, even before standard developers have the opportunity to use them. These sorts of negative comments are a sign that the tool is becoming mainstream, which is a good thing.
- adriand 15y ago
  This is a good, solid assessment of what Rails 3.2 is like to work with. Like you, I don't totally understand where the animosity towards Rails is coming from. If you want to make a drum machine that runs in your browser, like Giles Bowkett, then perhaps Ruby on Rails is really not good for you. On the other hand, if you want to earn a living, then the tremendous ease with which you can produce a reliable, secure, and full-featured application with Rails is really quite astounding. I do think that some of the criticism around the thick-client support in Rails is justified, however. Rails was ahead of the pack when it came to AJAX support in the early days, but it is not leading the way when it comes to thick-client architecture. At the same time, however, when the core developers announced that Rails would default to Coffeescript, half of the developer community freaked out, including many people here on HN. At this point, there are so many people with a stake in Rails it is impossible to please them all.
teolicy 15y ago
I’m not a Rubyist, but I’ve written a post recently about using PATCH to increment/decrement counters atomically. Perhaps it could be of value here, I’d love to see it in Rails: http://tech.blog.aknin.name/2012/02/08/restfully-atomically-incrementing-a-counter-using-http-patch/ http://tech.blog.aknin.name/2012/02/08/restfully-atomically-... (commented this on the article as well)
jamesu 15y ago
Will be interesting to see if and when we'll see another Rails fork.
jashkenas 15y ago
Nice to see the "official" Node.js response to this change... > "Rails to use PATCH instead of PUT" Http nerds annoy me > "it's actually doing is un-breaking HTTP caching > and proxying semantics" ... roll eyes - ryah https://twitter.com/ryah/status/173683063371464704 https://twitter.com/ryah/status/173683063371464704 https://twitter.com/ryah/status/173683909723291648 https://twitter.com/ryah/status/173683909723291648
- ksec 15y ago
  Could someone care to expand and explain more on this?
  - grabastic 15y ago
    Sure... Ryan is being snarky on Twitter. :)
chubot 15y ago
Honest question: Why isn't POST the "primary HTTP method for updates"? The way I've understand it is that GET is for reads (which are always idempotent), PUT is an idempotent write and POST is a non-idempotent write. I don't see what PATCH adds over POST.

195 points by anthony_franco 15y ago

The concern is not whether "my web server" will understand PATCH, but whether the random proxy between my web server and the client will; I'm totally willing to believe it does (1995 is a long time ago, I've certainly used and heard about PATCH, and even more elaborate WebDAV methods like PROPPATCH are used by Subversion without serious issue), but to ask about the web server and ignore the proxies is disappointing.

aaronblohowiak 15y ago
_method param is used to override the true http method with the one rails should use for routing, so everything can go over vanilla POST
- binarysoul 15y ago
  yes this is exactly right, its POST for compatibility reasons, rails puts a special parameter in the form submit to map to PUT (for resourceful routes)
SystemOut 15y ago
As I currently work in the K-12 educational software industry this is something I would be extremely sensitive to. The sheer number of creaky, old proxy servers out there that we have to contend with is mind boggling. I'm sure others have to deal with this to but I suspect that the education market is one where people will run into surprises and most likely won't realize what the issue is right away. As the sibling post pointed out there is way to change the http method used but I suspect most people won't do this or know about this and this is a really really hard thing to QA for.
- tptacek 15y ago
  I have a hard time believing that Rails programmers will use resource routing and not understand _method. It's pretty fundamental to the way the framework works. Are you a Rails dev? If not, just know: for the most part, we're talking about different flavors of HTTP POST.
  - ryanto 15y ago
    At the time of reading your comment it is light gray. I am not sure why people are downvoting you... _method is a pretty important part of the rails routing and solves a lot of the proxy/server problems that people are mentioning. In fact, I would argue that things like put/patch/_method are what make Rails so great. Rails makes a lot of strong opinions (put, whoops no, patch!), but then at then end of the day always gives you a way (_method) to deal with any issues where their opinions may not work in your current architecture. This pattern appears throughout the framework and is one of the reasons I really enjoy Rails.
  - apike 15y ago
    The concern isn't simply that there will be Rails programmers in K-12 that don't know how to override an HTTP method. The concern is that when K-12 users are using Rails 4 apps (that may or may not be K-12 specific) they may fail in bizarre ways that are hard to troubleshoot.
    - lparry 15y ago
      It's not an issue because web browsers only support GET and POST. Rails works around this by including a hidden field "_method" which contains the method the server should treat the request as.
      - justincormack 15y ago
        That's not true xmlhttprequest should support all methods but there are some quirks eg see http://www.mnot.net/javascript/xmlhttprequest/ http://www.mnot.net/javascript/xmlhttprequest/ to test though that does not cover PATCH.

mitchellh 15y ago

I don't use Rails anymore, but I did professionally for 3.5 years, so I think that gives me the right to a strong opinion on this, so here we go: Why are they even bothering? Really, who cares about PATCH vs. PUT? If PATCH even has a remote chance of breaking 0.01% of sites, then WHY do it? PUT works fine. I don't care. I don't care either way, actually, since I don't use Rails anymore, just put PATCH in. But my main concern is: Why is this major blog post worthy for Rails? I want to see something like "Rails 4: Damn Simple Websockets" or something to show that Rails is modernizing. I spent some time playing (read: nothing serious) with Lift and Scala, and while I wouldn't use that full time, it is clear to see that Lift has a handful of features that are just amazing for a modern website that Rails completely lacks (ridiculously simple AJAX/websocket stuff, triggering UI elements based on data model changes in the backend, etc.). Anyways, its so early that Rails 4 is still a big unknown, but this is not the PR start I would've liked to see.

batista 15y ago
If PATCH even has a remote chance of breaking 0.01% of sites, then WHY do it? PUT works fine. I don't care. Well, this "if it even remotely breaks 0.01%" and "I don't care" attitude is the main reason things get bloated and stop progressing.
- moe 15y ago
  We seem to have different ideas of progress. To my eye Rails is picking up bloat like there's no tomorrow and happily adopting questionable decisions like the above. Meanwhile fundamental issues remain largely unaddressed. There's still serious performance regressions. The asset pipeline is still sort of a trainwreck. There's still no automation for schema migrations (perhaps hobo fields will finally bring some relief for those who adopt it). They still don't seem to have realized that code generators are a no-go. I see zero efforts towards modernizing the bloated routing and MVC cruft to accomodate modern fat-clients (and imho the "resources"-magic was a terrible idea from the start even for regular apps). The whole thing is still riddled with ungodly amounts of magic that likes to break in unpredictable ways (my pet bug: the monkey-patch to really suppress browser stack-traces in production changes about every 3 months and it's worrying such a bug was deliberately created in first place). I could go on for a while... </rant>

minikomi 15y ago

Interesting to say the least seeing this on the front page lined up with "right" vs "pragmatic".

nfm 15y ago

See also the lengthy GitHub discussions about this issue: https://github.com/rails/rails/issues/348 https://github.com/rails/rails/issues/348 https://github.com/rails/rails/pull/431 https://github.com/rails/rails/pull/431 https://github.com/rails/rails/pull/505 https://github.com/rails/rails/pull/505 https://github.com/rails/rails/pull/5130 https://github.com/rails/rails/pull/5130

kennystone 15y ago

Not the good kind of innovation. Some nerds won an argument about HTTP semantics. Rails used to understand the importance of convention. This just seems silly and meaningless, change just for change.

homosaur 15y ago
Maybe it is, maybe it's not, but I don't think moving from technically incorrect to technically correct is change for change's sake. There's benefits to doing things by spec even if they are not immediately obvious. I think what you're saying though is that the downsides are. You may be right on that, but I'm going to withhold judgement until I really figure out what this means.
deleted 15y ago
[deleted]

samd 15y ago

Rails never used PUT correctly to begin with. Everybody uses update_attributes which does partial updates. Ideally you wouldn't need to do partial updates and just send the entire resource; your resources shouldn't be so big that that's an issue. It's much simpler than making the front-end decide when to do full versus partial updates and which method to use. Rails can't really do that though, too much legacy code out there, too many people set in their ways. Resorting to PATCH is their only option if they want to use HTTP correctly.

wccrawford 15y ago
Thanks, I was just wondering about this. I've never written a REST service in Rails, but when I wrote one (after doing a lot of research), it seemed obvious to me that partial updates are an absolute necessity. I had actually thought to try to use a Rails-based REST service in the future, because I thought it would be quicker than rolling my own again (I had no choice, honest!) but without partial updates, I couldn't use it.

functionform 15y ago

what a pointless change.

monsterix 15y ago

On the contrary, I feel Rails is in an awesome direction now. Here is why: Playing with rails for more than 3 years, and then suddenly something new comes and hits you is obviously going to hurt. Let me start with the Assets Pipeline, and in particular - style & script. Did you feel that it is important to control the no. of bits and bytes going into your css now? Until Sprockets came by, people would drop a load of crap in the public/stylesheets (bloated with properties !importants and all). Continuing this way, is going to affect your app's responsiveness on new landscapes - aka tablets, hand-helds especially if you're thinking about "app-development with non-native approach" in your mind. I mean it's not about syntactic sugar alone. It's about the ability to see what can be removed completely from the code and dried up to give desired result with maximum re-usability. Now I'd credit this to the "direction of rails" which served SASS/SCSS or coffeescript as default. It forced me to think and add programming logic into style. Personally, I like it. Also what fails me, is the classic nodejs vs Rails war. Let me re-word this: It is a classic unfounded flame-war, as described in HN guidelines. Both technologies have a place and are useful for even more mutually-exclusive scenarios. Why compare?, just do you own thing! To sum it up - there is a need to take a step back and consider the idea "you wouldn't bump on something new thing or useful with status quo." I would definitely like to consider PATCH over PUT.

dirtyhand 15y ago

jumped the shark, Rails has

dlitz 15y ago

What it's actually doing is un-breaking HTTP caching and proxying semantics, so that we can meaningfully deploy those caches and proxies in a few years. That should help with scalability, and performance at scale. For example, if PUT is actually implemented properly, then you can implement write-back caching semantics with a general-purpose HTTP proxy. The way that Rails currently abuses PUT, a general-purpose proxy can only implement write-through caching (at best), or it needs to be customized for the specific application in use. Also, it's standardizing the language that developers are using to interact with each other, and reducing the amount of work needed to build interoperable software. As more and more websites turn into web services (even if those services are only consumed by e.g. client-side Javascript), this should result in cost savings and faster time-to-market as more businesses move in that direction. Finally, a lot of web apps are basically just CRUD (create/read/update/delete) apps. The more we standardize the on-the-wire protocols for these routine operations, the more we can push those protocols into application frameworks. This means that, as developers, we can work on things that are actually valuable, rather than coming up with new, site-specific ways of shuffling this data around the network.

subleq 15y ago
How is a write-back cache possible in an HTTP proxy? I understand write-through caching for PUT requests (The proxy doesn't have to repeat future identical PUTs because PUT is idempotent), but how does the proxy know what the response to the original PUT request is unless it performs the request against the origin server immediately? Edit: I just noticed that RFC 2616 mandates write-through behavior: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.11 http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...

jkahn 15y ago

There is a huge amount of hate on HN against Rails lately. Most of it amounts to the straw man attack of "Rails is bloated and old, Node/insert tiny framework here is where it's at". I code with Rails. With Rails 3.2, I'm more productive than I've ever been. What others call "bloat", I call "features". It is surprisingly good having an out of the box asset pipeline for optimization of JS/CSS. The simplicity with which you can construct and adjust scoped queries with ActiveRecord is astounding. The ease of adding pre-baked authentication and authorization gems is great. Seriously - screw writing a large data-driven web app in a tiny framework. You get so much for free in Rails. Yes, Rails has some issues. It has a long initial load time. Ruby is not the fastest language. My main complaint about Rails at the moment would be that it moves too quickly - not that it moves too slow. If you're writing an app to service millions of users simultaneously (and not charging for it), the speed might be an issue. I haven't found it to be a problem in my company, where we charge money for what we write. And on this change - I'm not fussed either way, but it's certainly good that Rails core mention this on the Rails blog so that Rails developers are aware of it well before 4.0 comes out. And standards compliance is a good enough reason for me.

ticks 15y ago
The way I see it, HN has lots of people who jump on and off of bandwagons, even before standard developers have the opportunity to use them. These sorts of negative comments are a sign that the tool is becoming mainstream, which is a good thing.
adriand 15y ago
This is a good, solid assessment of what Rails 3.2 is like to work with. Like you, I don't totally understand where the animosity towards Rails is coming from. If you want to make a drum machine that runs in your browser, like Giles Bowkett, then perhaps Ruby on Rails is really not good for you. On the other hand, if you want to earn a living, then the tremendous ease with which you can produce a reliable, secure, and full-featured application with Rails is really quite astounding. I do think that some of the criticism around the thick-client support in Rails is justified, however. Rails was ahead of the pack when it came to AJAX support in the early days, but it is not leading the way when it comes to thick-client architecture. At the same time, however, when the core developers announced that Rails would default to Coffeescript, half of the developer community freaked out, including many people here on HN. At this point, there are so many people with a stake in Rails it is impossible to please them all.

teolicy 15y ago

I’m not a Rubyist, but I’ve written a post recently about using PATCH to increment/decrement counters atomically. Perhaps it could be of value here, I’d love to see it in Rails: http://tech.blog.aknin.name/2012/02/08/restfully-atomically-incrementing-a-counter-using-http-patch/ http://tech.blog.aknin.name/2012/02/08/restfully-atomically-... (commented this on the article as well)

jamesu 15y ago

Will be interesting to see if and when we'll see another Rails fork.

jashkenas 15y ago

Nice to see the "official" Node.js response to this change... > "Rails to use PATCH instead of PUT" Http nerds annoy me > "it's actually doing is un-breaking HTTP caching > and proxying semantics" ... roll eyes - ryah https://twitter.com/ryah/status/173683063371464704 https://twitter.com/ryah/status/173683063371464704 https://twitter.com/ryah/status/173683909723291648 https://twitter.com/ryah/status/173683909723291648

ksec 15y ago
Could someone care to expand and explain more on this?
- grabastic 15y ago
  Sure... Ryan is being snarky on Twitter. :)

chubot 15y ago

Honest question: Why isn't POST the "primary HTTP method for updates"? The way I've understand it is that GET is for reads (which are always idempotent), PUT is an idempotent write and POST is a non-idempotent write. I don't see what PATCH adds over POST.