4 ms·

It's a shame that Patch isn't idempotent. My preference for updating data across the web is to send only the information that is different, and the service ens

by scott_w 14y ago

It's a shame that Patch isn't idempotent. My preference for updating data across the web is to send only the information that is different, and the service ensures everything else remains the same. Put doesn't quite cut it in this case (technically, it's supposed to completely replace a resource). Are there any advantages for declaring Patch to be not idempotent? I'm assuming it allows appending to a single resource?

ibotty 14y ago
yes. to quote the rfc: There are also cases where patch formats do not need to operate from a known base-point (e.g., appending text lines to log files, or non- colliding rows to database tables) [...]
- scott_w 14y ago
  Yes, I saw that. Personally, I think Post does a good enough job for that. I know it's technically supposed to create a sub-resource, but it seems to work for appending to the same resource just as well. I'm a little uncertain of the case for using Patch to append rows to a database. Surely that's a case where Post does a better job?
  - rfugger 14y ago
    POST would make more sense if each row is its own resource. PATCH would make more sense if the entire table is its own resource, without addressable sub-resources (rows).
    - scott_w 14y ago
      As far as the spec is concerned, yes I agree. On a more personal level, I'm of the opinion that Post can append to an existing resource, without adding a new resource. Allowing for this practicality in the spec would allow Patch to be only idempotent.
      - ibotty 14y ago
        that would be nice, indeed, but seems impossible now.
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".
m_eiman 14y ago
Wouldn't combining it with an If-Match header make it idempotent, assuming the server actually performs the check before applying the patch?
_mhp_ 14y ago
Section 2 contains: A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes [...] Clients using this kind of patch application SHOULD use a conditional request [...] For example, the client can use a strong ETag [RFC2616] in an If-Match header on the PATCH request. So you can, but aren't obliged to.
zedr 14y ago
Concurrent clients PUTting and PATCHing of a single resource. Successive (not sequential) PATCHes are not guaranteed to produce the same outcome.
bruth 14y ago
Conditional requests are the way to go to be more transparent to clients, but the server implementation can _test_ values prior to patching the resource. For example, the JSON Patch spec has a "test" operation: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02#section-4.6 http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02#... so you could accept the same patch, but simply test if the resource is up-to-date before patching it.
zacharyvoase 14y ago
Coincidentally, I recently read this article, entitled “You Cannot Correctly Represent Change Without Immutability”: http://tapestryjava.blogspot.se/2012/07/you-cannot-correctly-represent-change.html http://tapestryjava.blogspot.se/2012/07/you-cannot-correctly... The point is, the ‘patch’ itself is a transformation defined by a 2-tuple of the old value and the delta (whereas a ‘put’ would be defined as the 2-tuple of the old value and the new value). Because the old value is referenced by the request URI (which is mutable), simply specifying the delta itself is not idempotent. Of course, following the RFC's advice and adding the ETag means you're specifying both the delta and the old value, which makes the operation idempotent.

by scott_w 14y ago

ibotty 14y ago

yes. to quote the rfc: There are also cases where patch formats do not need to operate from a known base-point (e.g., appending text lines to log files, or non- colliding rows to database tables) [...]

scott_w 14y ago
Yes, I saw that. Personally, I think Post does a good enough job for that. I know it's technically supposed to create a sub-resource, but it seems to work for appending to the same resource just as well. I'm a little uncertain of the case for using Patch to append rows to a database. Surely that's a case where Post does a better job?
- rfugger 14y ago
  POST would make more sense if each row is its own resource. PATCH would make more sense if the entire table is its own resource, without addressable sub-resources (rows).
  - scott_w 14y ago
    As far as the spec is concerned, yes I agree. On a more personal level, I'm of the opinion that Post can append to an existing resource, without adding a new resource. Allowing for this practicality in the spec would allow Patch to be only idempotent.
    - ibotty 14y ago
      that would be nice, indeed, but seems impossible now.

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

m_eiman 14y ago

Wouldn't combining it with an If-Match header make it idempotent, assuming the server actually performs the check before applying the patch?

_mhp_ 14y ago

Section 2 contains: A PATCH request can be issued in such a way as to be idempotent, which also helps prevent bad outcomes [...] Clients using this kind of patch application SHOULD use a conditional request [...] For example, the client can use a strong ETag [RFC2616] in an If-Match header on the PATCH request. So you can, but aren't obliged to.

zedr 14y ago

Concurrent clients PUTting and PATCHing of a single resource. Successive (not sequential) PATCHes are not guaranteed to produce the same outcome.

bruth 14y ago

Conditional requests are the way to go to be more transparent to clients, but the server implementation can _test_ values prior to patching the resource. For example, the JSON Patch spec has a "test" operation: http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02#section-4.6 http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-02#... so you could accept the same patch, but simply test if the resource is up-to-date before patching it.

zacharyvoase 14y ago

Coincidentally, I recently read this article, entitled “You Cannot Correctly Represent Change Without Immutability”: http://tapestryjava.blogspot.se/2012/07/you-cannot-correctly-represent-change.html http://tapestryjava.blogspot.se/2012/07/you-cannot-correctly... The point is, the ‘patch’ itself is a transformation defined by a 2-tuple of the old value and the delta (whereas a ‘put’ would be defined as the 2-tuple of the old value and the new value). Because the old value is referenced by the request URI (which is mutable), simply specifying the delta itself is not idempotent. Of course, following the RFC's advice and adding the ETag means you're specifying both the delta and the old value, which makes the operation idempotent.