7 ms·

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

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>
  - fxn 15y ago
    Patches welcome!
    - malandrew 15y ago
      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.
      - homosaur 15y ago
        Does this mean it's time to fork?
        virmundi 15y ago
        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.
- malandrew 15y ago
  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.
  - jshen 15y ago
    "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.
    - malandrew 15y ago
      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?
fxn 15y ago
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.
- grabastic 15y ago
  I'm glad to see this make it into 4. I'd love to see it get backported to 3.
- lucisferre 15y ago
  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 15y ago
    How is sending partial state incompatible with idempotency?
deleted 15y ago
[deleted]
grabastic 15y ago
"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? And if you don't care... what's with the rant?
almost 15y ago
It does matter. The more you build on predictable standards in one place the simpler things get in others.
pilif 15y ago
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.
- lucisferre 15y ago
  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.
  - dasil003 15y ago
    How should the controller enforce idempotence though? That is a model concern.
tripzilch 15y ago
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.
- rue 15y ago
  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…
some1else 15y ago
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?
- ksec 15y ago
  I thought i was the only one who see this. Why haven't the blog been updated to something much more useful?
davedx 15y ago
Out of interest, what do you use now instead of Rails?

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>
- fxn 15y ago
  Patches welcome!
  - malandrew 15y ago
    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.
    - homosaur 15y ago
      Does this mean it's time to fork?
      - virmundi 15y ago
        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.
malandrew 15y ago
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.
- jshen 15y ago
  "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.
  - malandrew 15y ago
    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?

fxn 15y ago

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.

grabastic 15y ago
I'm glad to see this make it into 4. I'd love to see it get backported to 3.
lucisferre 15y ago
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 15y ago
  How is sending partial state incompatible with idempotency?

deleted 15y ago

[deleted]

grabastic 15y ago

"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? And if you don't care... what's with the rant?

almost 15y ago

It does matter. The more you build on predictable standards in one place the simpler things get in others.

pilif 15y ago

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.

lucisferre 15y ago
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.
- dasil003 15y ago
  How should the controller enforce idempotence though? That is a model concern.

tripzilch 15y ago

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.

rue 15y ago
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…

some1else 15y ago

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?

ksec 15y ago
I thought i was the only one who see this. Why haven't the blog been updated to something much more useful?

davedx 15y ago

Out of interest, what do you use now instead of Rails?