3 ms·
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"
by 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 agoHow should the controller enforce idempotence though? That is a model concern.