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.
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.
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.
Because browser support for any method but POST and GET still is spotty at best, your fears of breakage are totally irrelevant because rails still has to use the POST method and set some flag (_method in params) to cause the backend to interpret the POST as a different method.
The PATCH method thing only becomes relevant in conjunction with APIs where I would hope that you have enough control over your environment to not having to deal with broken proxies.
On the upside, using PATCH instead of PUT, in the context as PUT is used most often these days (partial updates) is more compliant with HTTP which says that the body of a PUT request should contain the whole resource, not just parts that change.
The problem is there is nothing in rails controller design that actually makes an update "restfully" idempotent. It's trivially easy to end up with a "updated" field that updates anyways, or other side effects, in which case neither PUT nor PATCH make sense.
In a good majority of API cases the correct method is POST, even for so-called updates. Because, generally speaking, it is the controller that decides what happens to state when processing the request in Rails and if and when there will be side effects. Unless you can be certain the client will decide 100% of the result of the state PUT and even PATCH are just not technically correct.
PATCH is arguably better suited than PUT here but again why the strict adherence to one or the other for updates, when quite possibly neither is correct. Why PATCH by default? Why not just POST by default, PATCH/PUT where they make sense? In the end there is nothing specifically RESTful about Rails, it has no real resources or hypermedia to speak of so I can understand why people would question the real value of this move.
"Why are they even bothering? Really, who cares about PATCH vs. PUT?"
Lots of people care. It's about following existing standards to allow for more predictable behavior. What if people didn't care about status code 200 vs 404?
So, I'm reading a lot of reasoning, but not many good reasons yet. Can anyone follow through on why PATCH vs PUT is better?
Assume I'm stupid.
Explain to me, but don't stop at "because it's more compliant to the HTTP Standard" / "because thus it has been written in the scriptures" mustn't be the fundamental reason to do something.
Similarly, "it is Good to be compliant with the HTTP Standards in this case, because in other cases it was Good also"--certainly I can understand that being compliant with the 200 and 404 status code is a Good Thing.
But is there any other, tangible reason why a Rails project would benefit from now using PATCH instead of PUT? Some interoperability with another existing framework maybe? Or interoperability with a hypothetical future framework? What other kinds of software would need to be changed and used before it'll provide a tangible benefit to a Rails project that uses PATCH vs a Rails project using PUT?
BTW I'm not arguing against standards (I know, I said you may assume I'm stupid, but no need to go all out ok?), I'm just genuinely curious if there is any other benefit, real, future, hypothetical or imaginary, other than "it's more compliant, and being compliant is good".
Actually even if that is the only reason, that's nice, it makes things neater and that's also good. But it would be kind of thin.
They're different things, just like eating and drinking are different things. I don't really know what Rails is doing with them, but it's a really simple reason at the HTTP scope.
PUT is A) idempotent (meaning that repeated operations have the same result), and B) always replaces the entire resource (and by implication should contain the entire new resource).
PATCH is A) not idempotent (meaning that repeated invocations could have different results), and B) affects part or all of the resource.
So, an immediately obvious benefit[1] is that PATCH requests are potentially much lighter-weight.
[1] Aside from conceptual clarity which I frankly cannot fathom reasons for arguing against, yet many do…
We can all agree that Rails has stalled for the past couple of years because of refactoring. Question is, would Rails really have much more to show if new features were crammed onto the 2.0 architecture?
It seems like the post is intended to highlight a high quality commit which somebody worked hard on, as well as prepare the community for a semantic change. It may not be worth touting as much as a competitive feature, but it certainly deserves it's place in the feed.
But really, the only thing that bothers me with this post is the under-developed blog it's been running on for years (ie.: no simple way to get to archives, next or previous post, etc).
Advocating against PATCH is near to advocating against the introduction of RESTful routes and controllers, which was a crucial gain for Rails (even though they probably got the hint from Django?).
P.s.: Socket.io isn't part of Node.js core either. There are implementations in Ruby, but why not just use Node and Socket where appropriate?
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 think the problem is beyond being solvable by patches, but an issue of philosophical introspection of where Rails wants to be in a few years.
To be able to change the direction of Rails on this issue and the other issues the poster above raised, I'd have to spend a significant amount of time submitting patches and get to the point where I am a major committer to have the opportunity to chime in and have a significant impact on the direction Rails is going. Even if I or someone else with the same concerns were committed to making that effort, by the time I or they get to the point where we can have an impact, it will be too late.
I'd rather commit to a node or an npm package than rails because any package I commit to will hopefully be replaced by something better once it's outlived its usefulness. My favorite part about node is that it isn't opinionated. It leaves the opinion to the community modules. Hopefully most community modules with maintain just the right amount of opinion about their domain and know when to concede matters of opinion to other modules that node better. It's nice when separation of concerns is a cultural value.
This isn't a node/rails debate. It's a values debate. I think opinion was the right value for the right time several years ago. We're going through a time of change where opinion is a liability not an asset.
"My favorite part about node is that it isn't opinionated. It leaves the opinion to the community modules."
Node is not opinionated because it is not a framework; it is a JavaScript environment built on V8 and some common libraries. It would be much more appropriate to compare Express* with Rails than Node with Rails.
If you want to compare Node with something you'd be more correct comparing Node and its modules with Ruby and its gems.
* Even though, from what I can see, Express has more in common with Sinatra than Rails...
Express is more like Sinatra. It's largely syntactic sugar and some powerful extra features beyond what node's http module offers.
Express knows where its "opinion" ends and where it should make room for other modules with opinions of their own.
There really are two opinions at play here. Opinions of how to do something and opinions of what to do.
Express has opinions of how that differ from the http module (it even uses the http module to accomplish what it does).
Express has a minor opinion on what it should be doing and extends the what beyond the http module, but that's largely where it ends.
The problem with Rails is that it the domain of subjects it had an opinion on kept growing until it couldn't not have an opinion on stuff.
CSS versus SASS? I love Sass and used it before Rails added it. Rails didn't need to have an opinion here.
Coffeescript? Same thing.
Maybe it is an unfair comparison because there's no equivalent to this much opinion about so many things in the Javascript world, except some Rails ports that people have made. And even they are seen by most as "Oh that's nice that you can get set up quickly in less than a day, but no thanks, I'd like to pick and choose what makes sense to me based on what I'm planning on building."
Had we known better maybe we would have gone with Sinatra back when we started.
Given what you've described I'd suggest you take just one more friendly unbiased look at Rails 3... and if after that it's still not your cup of tea then fair is fair. Maybe you won't choose to develop with it, but maybe you also won't choose bash it. It's pretty cool and I believe it was an attempt by Rails developers to address your very concerns. Most major components can now be easily swapped via Railties thanks to the decoupling efforts.
Don't get me wrong. I really like Ruby, but I think Rails has become too all encompassing in places.
The architecture, like railties look pretty cool, but policy of constantly embrace and extend just leads to bloat that gets in the way when you're doing something more exotic than straight server-side CRUD.
"It's a values debate. I think opinion was the right value for the right time several years ago. We're going through a time of change where opinion is a liability not an asset."
I think this may be becoming more true everyday, but I still don't think we've come to the point where anyone has discovered The Way to do web stuff. Rails continues to introduce ideas that are interesting and important. Would CoffeeScript and Sass have received such rapid uptake if not for Rails? (Some of you may think that would be a good thing)
This is a horrible issue with modern development. Basically we are getting into sectarianism. Don't like a doctrine of the Brethren Church? Fork and become the Grace Brethren. Don't like a small doctrine of the Grace Brethren? Fork and make the Conservative Grace Brethren.
I know that GIT and the like have made it really easy to fork and run, but does this fundamentally help? Does having X versions of some framework really make sense?
Why not go a different route and just give up the one side and make another? Rather than forking, make something new.
> I know that GIT and the like have made it really easy to fork and run, but does this fundamentally help?
Yes, it does. What ends up happening in practice is that forks are almost always short-lived. They either get merged with the mainline, they become the new mainline, or they die out. Occasionally, there are two self-sustaining projects that diverge from the same point of origin, but it's rare.
Yeah, I actually think that's the way to go if you don't like Rails, I was kind of joking. I am curious to see if there's enough passion for Rails itself that people would say, "no I want RAILS, even if it means making it something else" rather than just accepting a change in philosophy or moving to something else.
Personally, I think there's not. I think people either are sticking to Rails or they are not. I think even if you don't like the new Rails, it did help the development community at large. Before Rails, I don't know many web folks who were talking about TDD and MVC and real, honest, programming stuff.
The question is whether the patches would be accepted. There are still people in charge. When they make a choice to go route A and you say: I have a great patch to make route B work, they are not going to take it. Secondly, if you disagree with an architectural decision, you can't be expected to make the chosen architecture work. Especially not if your patch may be rejected anyway.
The number of patches that get rejected is staggering. Practice shows that 'patches welcome' is just not true.
Downvoted you both. Both attitudes are neither arrogant nor absurd. They just stem from different expectations and beliefs. These kind of statements aren't going to convince anyone. Explain why they are wrong. 'Being arrogant' is not an explanation: it's an accusation, that'll immediately get the other on the defensive.
I don't understand your comment. Are you suggesting one side of the above argument implicitly condones slavery? Or do you feel that my argument is invalid, because it could equally apply to a discussion about slavery in which people resort to name calling?
Now you're just being deliberately obtuse. Nobody needs to be told that demanding unpaid labor of open-source contributors is condoning slavery, and nobody is owed an explanation of why unless they're a small child or mentally handicapped.
Eta_carinae did not demand that open source authors fix any problem a user complains about. He only stated that the exact opposite attitude is not a good idea. Arguing against A is not the same as arguing in favor of (not A), because there are more than 2 possible positions on the issue.
Similarly, cheald does not demand that users of open source projects contribute fixes for bugs. He also only stated that the exact opposite attitude is not a good idea.
Arguing either of those extremes is pointless: the discussion starts polarized and neither side will yield an inch. Introducing slavery into the discussion doesn't help.
Most authors of open source projects are interested in having their projects be used by many others. It is the usefulness to many others that provides a sense of accomplishment. If they don't pay some attention to problems those others encounter and for instance fix clear bugs in early releases, their chances of achieving that goal are lower. Observing this fact about the system is not argument in favor of slavery. There are no normative statements involved.
Similarly, if you, as a user of an open source project, want some bug fixed, the best way to go about it is often to write the code yourself and offer it for inclusion. That suggestion does not reduce them to slaves either.
To make a bazaar work, all parties involved have to be flexible in their expectations.
Huh? The time I've invested in open-source contributions has had payoffs massively greater than any work I've ever done for a paycheck. It's just not necessarily that I get paid for the work, rather, I get paid because of the work.
Maybe your experience with open-source is different. I think most contributors do it for joy, anyway.
Has the entire population of HN suddenly lost the ability to comprehend English?
Demanding unpaid labour has nothing to do with you or anyone else volunteering labour. My words cannot possibly be construed as saying volunteer work in open source is slavery.
Even the top ranked essay on exploitation of the free software industry[1] disagrees with you:
"I do not believe that engineers creating software for other engineers results in exploitation."
Squeaky wheel driven development is not slavery. Users are "free" to demand features, and developers are "free" to ignore the requests. Your premise is absurd.
You have utterly lost the context of the thread, which was an insufferable fool whining about developers welcoming patches instead of doing whatever is demanded of them.
It's beyond me why rails thinks it should dictate how to write/manage/package javascript.
As a newbie-ish javascript developer I am continually learning from great projects like requirejs, enderjs, nodejs, commonjs (AMD in general), backbonejs, etc.
How arrogant do rails programmers have to be to dip their hand into javascript best practices? Honest question, because the better I get at programming the more I feel like rails is less necessary.
They're not dictating how you use JS, best practices, or anything like that, it's simply a pipeline for compressing and delivering assets. You also don't have to use it if you don't want to. There is a "config.assets.enabled" option in application.rb that you can set to "false" to turn it off.
Bottom line is Rails is, and always has been, and opinionated framework, which you choose to buy in to. And even in recent years they've been better about letting you opt out of certain parts of it.
How do you minify and concatenate your files in your projects? Part of a deploy/build script? Commit hooks? Manually? Do you do it at all? What about compiling Sass and CoffeeScript?
The asset pipeline is not arrogance it's convenience. If you have a better system for those tasks then you shouldn't use the pipeline, but for a lot of people the asset pipeline saves time and results in a faster, better experience for their end users.
Completely agree. However, instead of bundling one asset pipeline into rails that is "aggressive" like Sprockets about getting into everything, they should have said "here's a connector" where you can attach the "asset pipeline" of your choice and let the community create the tools it needs for different scenarios, such as one asset pipeline for thin clients and another for think clients. Or separate asset pipelines for sass/css and coffeescript/javascript.
Bundling a default that doesn't play well with lots of the client-side innovations hurts rails more than helps.
The asset pipeline as it is currently designed is monolithic and an all or nothing approach.
I got downvoted into oblivion (deservedly so) because of my snark. But this is essentially the point I was trying to make. Rails is good at ruby. It was never good at javascript. Remember rjs? Remember inlining ajax handlers?
Now we have default coffee script and sass file _per_ view. I know they mean well but javascript is its own beast! I really don't want to have to consciously disable all these things that are supposed to "be convenient" just because I know my way around javascript enough to not co-mangle it in with ruby.
I agree, however Patch versus Put is the least of Rails' problem when it comes to bloat. Put vs Patch is bikeshedding.
An insistence on handling all things with Ruby is why things get bloated and stop progressing.
Sprockets solves a pain, I admit, but at the cost of adding ruby bloat to all thick client code.
Instead of being able to use javascript libraries with one another natively, everything goes through Ruby.
Anyways, I'll probably get downvoted for this comment by Railers because this is somewhat OT and trollish (I admit), but it's a legitimately complaint about the direction of Rails.
I think Rails has lost sight of what it does really well, server-side logic. Rails, in v4.0, needs to adopt a symbiotic relationship with thick-client javascript instead of trying to consume it and insert ruby in-between all the javascript parts.
For example, right now, the recommended place for a backbone.js app in a rails project is /app/assets/javascripts/. That "folder" is only going to grow as the client-side javascript becomes more important. Keeping the javascript logic "subordinate" to the Ruby elements in a Rails project causes more bloat than anything else. Look at any thick-client Rails project and count the number of gems managing javascript. If there are more than two or three, you've probably got a separation of concerns issue at the language level. That's bloat.
If you want to down vote me, go ahead. I just ask that you have the courtesy to defend your down vote with a comment. If you think I'm wrong tell me why. Maybe, I'm doing something wrong.
"Keeping the javascript logic "subordinate" to the Ruby elements in a Rails project causes more bloat than anything else. "
I have no idea what this means. how is it subordinate? The location on the filesystem?
"Look at any thick-client Rails project and count the number of gems managing javascript"
I've made a few that have no gems managing javascript. They talk to rails via REST. Rails doesn't need to care about them, and they don't need to care about rails.
By subordinate, I mean having your javascript assets managed by sprockets.
If you can tell me how I can get 100% of my javascript assets managed by javascript code and still allow the use of rspec for end to end acceptance testing, I'm all ears. How do you get Rails, at one point of contact, to had off all asset recompilation, concatenation, minification, cache busting through md5 fingerprint hashing, etc. to javascript, I'm all ears.
I wanted to use require.js before. Spent a couple days working it into the project, but couldn't get it to work because of incompatibilities with sprockets. Undid everything. Someone made a require.js rails plugin, and I tried it again. It turned out to be incompatible with how the jasmine gem works and the jasmine gem is organized the way it is because that's how gems are supposed to be organized. Again, after wasting several days trying trying to get everything to work, I tore it all out again.
It's like whoever designed sprockets hasn't even considered the possibility that maybe it should permit javascript to be used freely with javascript within a Rails projects without intermediating. Near as I can tell, all the intermediation is done to be able to such things as maintaining all the files in the same directory organization (app, config, lib, vendor).
I'd split things down into something like this to cleanly separate the concerns of ruby and javascript:
/client/
--/app/
--/config/
--/lib/
--/vendor/
--/spec/
/server/
--/app/
--/config/
--/lib/
--/vendor/
--/spec/
/shared/
--/stylesheets/ (if you render both static and dynamic. otherwise put this in the appropriate directory above)
--/config/
--/spec/acceptance/
How do you keep all your ruby out of your javascript?
It seems to me that your complaint is that Rails isn't written in javascript. If I'm understanding correctly, you want javascript on the backend. That's fine, but it's not really a critique of rails.
p.s. you don't have to use sprockets if it doesn't fit your needs. Your javascript can live outside of your rails app.
Thick javascript clients should probably live in a different project anyway. Create a rails project with the serverside stuff, a rest service layer. And another project containing just the clientside code, no ruby at all.
Then how do you test it if it's in another project? If you want to start stubbing out server logic in client tests and vice versa on the other side that seems very cumbersome and brittle.
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.
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.
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.
I swear it's like hipsters have taken over software development.
I'm very happy with where rails is at right now. I feel incredibly productive with it. I get to play with new fancy stuff because I know it's still there to bail me out and get it done fast when I need to.
I find neither a suit nor skinny jeans comfortable. Instead rails fits like a well worn in pair of jeans and a plain old t-shirt. Sell the hipster crap somewhere else.
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.
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?
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.
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.
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
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.
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)
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.
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.
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.
If everyone is going to be using _method, then there is no advantage to using a specific method at all. If I tell people "I have an API: you use PATCH to use it", but in fact if you do that it no longer works behind a ton of proxies, you either don't use it before shipping or it's too late.
Imagine if this was "we are using a new non-HTTP network protocol, and the answer to "how will you get it through proxies" is not "we tested it: it works" but instead "we have a way to tunnel it over HTTP"... that is a non-answer that undermines the entire purpose of having a new protocol, and restating it with pointlessly denegrating statements about people who don't know about the tunneling system doesn't help: it just makes the feature that much more questionable. :(
I don't understand. Either PATCH (and PUT and DELETE) work on (say) K-12 networks, or they don't. If PATCH doesn't work on K-12 networks, you have to tunnel; Rails does that with "_method", and every competent Rails programmer knows about "_method". If PATCH does work on K-12 networks, well, Rails supports it, and would in fact prefer you use it.
What's the complaint here? Rails can't do anything about shitty proxy software. It's there, and Rails works around it.
If PATCH does not work there, then you always need to tunnel. You do not know if the client is a K-12 network by User-Agent. If you always need to tunnel, you may as well define the protocol to be "you can use POST with _method now to say PATCH".
My "complaint" (I am not certain why you are using that term, as all I said was that I had a "disappointment" with the article announcing the feature) is that time was spent discussing "does my web server support it" (you can always change your webserver) as opposed to "will my client support it" (which is an interesting and important question).
(Also, it should be noted that Rails doesn't work around the "shitty proxy software": it provides a way to allow the client code to work around it, but it doesn't itself work around it. If there really are networks out there that don't route PATCH--which I didn't even believe in my original post, but was corrected with this K-12 failure--then you, the developer, are going to end up just never using PATCH.)
It may amuse you to know that your "new non-HTTP protocol" is basically describing SPDY, Google's new alternative-to-HTTP protocol, which is live and works in Chrome and e.g. any netty-powered webserver.
Look the counterfactual: any protocol (including HTTP...or TCP...or IP...) has "no advantages" unless both endpoints can understand it and the network can transmit it at the most appropriate layer. Until then, it requires tunnelling. That was definitely the case for the first rollout of TCP/IP, or HTTP.
It definitely doesn't imply that it shouldn't be done--the only thing that it implies is that it's harder work for the adopters until it has a critical mass of mind share and then it becomes harder for the non-adopters. If the alternative to that is no, or only centralized, improvements to protocols, I'll take the breakages.
I specifically thought of SPDY when I used that example; in fact, that's what makes it such a great example: SPDY asked themselves this question, and had a really great answer for it (specifically, that HTTP is used first, and only if the server opts in to using SPDY does it upgrade to a faster protocol, saving that information for later use).
The saddest part here is that I agree with you: I like that Rails decided to do this, and for the very reasons you describe. However, I expressed disappointment that this announcement/article decided to ask "will my web server support this" and didn't bother to ask "will the client be able to route to me with this".
Remember: I myself believed it would work, and even provided multiple reasons in my post for why it would. However, it would have been nice to see these points brought up in the article. If my version of nginx doesn't support it, I'll just upgrade, but if I'm honestly concerned about support, I'm going to care if I can even trust a PATCH to my client code.
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.
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.
This was more my point that I didn't get across correctly. When apps fail due to weird proxy issues they are incredibly hard to figure out and almost impossible to QA correctly for without a huge budget. And if this causes it, sure the Rails programmer might know how to solve it once they actually realize why it's failing. The why is the harder part.
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.
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.
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.
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.
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.