REST API PUT versus PATCH - is there in any point in PUT and PATCH?
There are several cases in the REST API where there is a PUT method that requires all fields to be present, and also a PATCH method which is the same except that not all fields are required.
Is there any actual benefit in those PUT methods? I can’t see what they offer over the PATCH methods.
Maybe its worth thinking about removing all PUT methods that don’t offer any substantial gain over the PATCH methods, reducing need for testing, documentation and complexity.
Here are the PUT and PATCH methods in the REST API:
AddressesVARUserPUT ListsVARArchiversPATCH ListsVARArchiversPUT ListsVARConfigPATCH ListsVARConfigPUT ListsVARConfigVARPATCH MembersVARPATCH MembersVARPreferencesPATCH MembersVARPreferencesPUT UsersVARPATCH UsersVARPUT UsersVARPreferencesPATCH UsersVARPreferencesPUT
as
On Feb 19, 2015, at 08:10 AM, Andrew Stuart wrote:
Is there any actual benefit in those PUT methods? I can’t see what they offer over the PATCH methods.
PUT is defined in HTTP/1.1. PATCH is (only) defined in RFC 5789, so it may not be universally supported. E.g. back in the restish days, I had to hack WebOb to support it, and it was an ugly hack, though Falcon supports it out of the box. I haven't dug into HTTP/2 enough yet to know whether PATCH has finally been adopted into the official standard.
Much of the philosophy of the REST API was influenced by RESTful Web Services (Richardson & Ruby), which IIRC recommended implementing both methods[*]. I recently received the follow up to that excellent book, RESTful Web APIs, but haven't really had time to read it yet to see how the intervening 6 years have changed their recommendations. A *very* quick skim of the first index hit provides some additional rationale as to why both are useful.
PUT is idempotent. If you send the same PUT request 10 times, the result is the same as if you'd only sent it once.
PATCH is not idempotent, but it can save on bandwidth and complexity. It's like a diff, in that it only contains the parts of the resource that have changed.
Cheers, -Barry
[*] Leonard Richardson was a colleague of mine on the Launchpad project back in the day. We had many conversations about Launchpad's REST API and his insights, expertise, and experience deeply shaped our current design.
No worries. It’s a little repetitious but doesn’t make much difference either way.
On 19 Feb 2015, at 8:34 am, Barry Warsaw <barry@list.org> wrote:
On Feb 19, 2015, at 08:10 AM, Andrew Stuart wrote:
Is there any actual benefit in those PUT methods? I can’t see what they offer over the PATCH methods.
PUT is defined in HTTP/1.1. PATCH is (only) defined in RFC 5789, so it may not be universally supported. E.g. back in the restish days, I had to hack WebOb to support it, and it was an ugly hack, though Falcon supports it out of the box. I haven't dug into HTTP/2 enough yet to know whether PATCH has finally been adopted into the official standard.
Much of the philosophy of the REST API was influenced by RESTful Web Services (Richardson & Ruby), which IIRC recommended implementing both methods[*]. I recently received the follow up to that excellent book, RESTful Web APIs, but haven't really had time to read it yet to see how the intervening 6 years have changed their recommendations. A *very* quick skim of the first index hit provides some additional rationale as to why both are useful.
PUT is idempotent. If you send the same PUT request 10 times, the result is the same as if you'd only sent it once.
PATCH is not idempotent, but it can save on bandwidth and complexity. It's like a diff, in that it only contains the parts of the resource that have changed.
Cheers, -Barry
[*] Leonard Richardson was a colleague of mine on the Launchpad project back in the day. We had many conversations about Launchpad's REST API and his insights, expertise, and experience deeply shaped our current design.
Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
participants (2)
-
Andrew Stuart -
Barry Warsaw