

PATCH Method for HTTP - dotpot
https://tools.ietf.org/html/rfc5789

======
scott_w
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?

~~~
quesera
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
By definition, GET, HEAD, PUT and DELETE are idempotent:
<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
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.

------
Arnout
Now annoyingly the ELB on AWS just bounces PATCH requests with a 405 Method
Not Allowed. Our services are affected by this and I noticed there is a bug
open over at Heroku regarding the same issue. It's something Amazon don't
document though so you only find out through testing after you already created
your planned stack...

~~~
rmccue
Indeed, it also affects <http://httpbin.org/> which makes it way harder to
test clients. Considering the spec has been out since 2010, you'd think they'd
have fixed it by now.

~~~
sjtgraham
It's a Request For Comments and not a standard. It's also at the most immature
level on the standards track. Why would they implement something that may
change drastically or never be implemented widely enough to justify the
engineering effort?

------
tamasnet
While this is certainly makes the request's intent more clear, I suspect there
isn't much gained here over simply POSTing the patch content. Other request
methods can be implemented by the HTTP server itself in terms of the
filesystem (e.g. PUT "simply" writes the content stream to a local file), but
PATCH would require the server itself to have specific knowledge of the patch
format and how to apply it in order to be useful. This could be farmed out a
plugin or external program, but such a thing could just as easily live as a
POST processor in [insert favourite language here] without needing to make any
changes to the HTTP server or standards.

------
almost
I gave a short presentation (5 minutes) about the PATCH verb and RESTful APIs
at local user group last year. Possibly someone will find the slide useful (or
just enjoy the kitten pictures ;p):

<http://almostobsolete.net/talks/http_rest_patch_kittens/>

------
sjtgraham
Can somewhere point me to the part of RFC 2616 that says "The PUT method is
already defined to overwrite a resource with a complete new body, and cannot
be reused to do partial changes."

~~~
fzzzy
This was the first thing that came to mind to me: can't PUT take a Range
header, and would that not be the same as patch?

------
munkydung
PATCH will be supported in Rails
[http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-
is-...](http://weblog.rubyonrails.org/2012/2/25/edge-rails-patch-is-the-new-
primary-http-method-for-updates/)

------
einhverfr
I can't wait to submit HTML forms with a PATCH method ;-)

~~~
kbanman
Could you elaborate on your sarcasm?

Given due care on server side, I'm not sure why that would be so terrible.

~~~
einhverfr
Because normally with a form you are submitting a full, complete resource from
the web server's perspective.

