3 ms·

HTTP PATCH can only be idempotent if the underlying patch mechanism is idempotent, right? At the protocol level, there are no guarantees. At the application le

by quesera 14y ago

HTTP PATCH can only be idempotent if the underlying patch mechanism is idempotent, right? At the protocol level, there are no guarantees. At the application level, you can fake it (in the non-mathematical sense) by checking sentinels/guids or testing for applicability. This provides safety, but requires code. But that's not really idempotence. I don't see any way that the IETF could specify a generic idempotent patch mechanism, or declare an arbitrary mechanism to be idempotent. EDIT: it looks like you want idempotence a la SQL UPDATE. That seems eminently doable in the application layer. Specifying it in an RFC would be inadequately generic for a whole new HTTP verb, I think.

rmccue 14y ago
By definition, GET, HEAD, PUT and DELETE are idempotent: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html I personally agree with the parent. PATCH should be idempotent; overwriting values with new values is idempotent and that should be written into the spec rather than avoiding it in favour of things like writing logs (which IMHO should be a POST).
- quesera 14y ago
  Yes, but GET, HEAD, PUT, and DELETE do very different things. You can write an idempotent PATCH mechanism. If that's what you want, you can do it. You control the server, so you can restrict the accepted patch formats to idempotent ones. Adding an HTTP verb doesn't make patching magically happen. Someone has to write the logic, either you or your framework authors. Obviously there will be different mechanisms and some will be effectively idempotent. Again, not in the mathematical or functional programming sense, but in the colloquial DBA sense, at least. Limiting HTTP PATCH at the protocol level would be a huge mistake, I think. None of this should be construed to mean that I see a clear need for a new HTTP verb, though.
Xylakant 14y ago
Note of care: SQL Updates are not idempotent. "UPDATE table SET a = a + 1".
- nfriedly 14y ago
  I love that for rearranging items in lists with user-defined orders. It lets you update the entire set with two commands - one to give the moved item its new position, and one to increase the position of every item after it.

by quesera 14y ago

rmccue 14y ago

By definition, GET, HEAD, PUT and DELETE are idempotent: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html I personally agree with the parent. PATCH should be idempotent; overwriting values with new values is idempotent and that should be written into the spec rather than avoiding it in favour of things like writing logs (which IMHO should be a POST).

quesera 14y ago
Yes, but GET, HEAD, PUT, and DELETE do very different things. You can write an idempotent PATCH mechanism. If that's what you want, you can do it. You control the server, so you can restrict the accepted patch formats to idempotent ones. Adding an HTTP verb doesn't make patching magically happen. Someone has to write the logic, either you or your framework authors. Obviously there will be different mechanisms and some will be effectively idempotent. Again, not in the mathematical or functional programming sense, but in the colloquial DBA sense, at least. Limiting HTTP PATCH at the protocol level would be a huge mistake, I think. None of this should be construed to mean that I see a clear need for a new HTTP verb, though.

Xylakant 14y ago

Note of care: SQL Updates are not idempotent. "UPDATE table SET a = a + 1".

nfriedly 14y ago
I love that for rearranging items in lists with user-defined orders. It lets you update the entire set with two commands - one to give the moved item its new position, and one to increase the position of every item after it.