4 ms·

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 th

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

by pilif 15y ago

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.