3 ms·

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 prop

by 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?

by fxn 15y ago

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?