
Rails 4.0: PATCH will replace PUT as the primary HTTP method for updates - anthony_franco
http://weblog.rubyonrails.org/2012/2/26/edge-rails-patch-is-the-new-primary-http-method-for-updates
======
mitchellh
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.

~~~
fxn
This is a blog post in the Rails blog because obviously this has to be
announced to the Rails community.

Any web framework has the duty to use and promote proper HTTP usage. Pushing
PATCH over PUT we are doing that.

This change is not the entire Rails 4.0, it is only _one_ change in Rails 4.0.
Rails 4.0 has still a long way to go.

And of course, there are going to be practical improvements as there have been
in all major (and indeed minor) versions. We will do practical improvements
_as well as_ being better HTTP citizens.

~~~
lucisferre
Sorry can you explain how using PATCH for updates by default is better and
promotes proper HTTP usage? I'm not REST expert but my understanding is that
using PUT as a default wasn't RESTful largely because you can't guarantee or
even rely on idempotency in the controller action and not just because
sometimes people were only be submitting the partial state of the changed
resource.

PATCH has the same idempotent requirement. It isn't simply some more generic
version of PUT intended for generic CRUD updates. As I understand, it is a
specific way to submit a "diff" of a resource to "patch" it so to speak.

PUT/PATCH verbs as far as HTTP/REST is concerned seem to have been designed
with literal management of resource data/state in mind. The primary scenarios
I can think of that require their use are things like blob storage APIs and
perhaps other types of direct content management scenarios. It just doesn't
seem appropriate as the general "update" mechanism that Rails is trying to
make it out to be.

I'm not saying the Rails way of doing CRUD is bad. It's a handy abstraction
and pattern that works fine for many, even most, cases, but as far s REST
goes, Rails is really just RESTful theatre. From what I can tell the most
RESTful thing Rails could do is just use POST by default everywhere and
provide a convenient way for the developers to use PUT/PATCH where and when it
truly makes sense.

~~~
dasil003
How is sending partial state incompatible with idempotency?

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

~~~
sandGorgon
Quick question - how do you work with the asset pipeline in _development
mode_. Did you not find it much, much slower than pre-asset Rails ?

~~~
jkahn
In 3.1 it ran like molasses in dev mode. Fortunately someone came out with the
rails-dev-tweaks gem that largely fixed that. 3.2 is fine in dev mode.

------
dlitz
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
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...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.11)

------
nfm
See also the lengthy GitHub discussions about this issue:

<https://github.com/rails/rails/issues/348>

<https://github.com/rails/rails/pull/431>

<https://github.com/rails/rails/pull/505>

<https://github.com/rails/rails/pull/5130>

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

------
jashkenas
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/173683909723291648>

~~~
ksec
Could someone care to expand and explain more on this?

~~~
grabastic
Sure... Ryan is being snarky on Twitter. :)

------
saurik
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
_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
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)

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

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

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

------
teolicy
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-...](http://tech.blog.aknin.name/2012/02/08/restfully-atomically-
incrementing-a-counter-using-http-patch/)

(commented this on the article as well)

------
monsterix
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
jumped the shark, Rails has

------
functionform
what a pointless change.

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

