Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



How is sending partial state incompatible with idempotency?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: