Welcome Guest, Not a member yet? Register   Sign In
Resource Routes - PUT vs PATCH
#11

(07-21-2017, 09:37 AM)natanfelles Wrote: Yes, with PATCH you can update as many attributes as you need individually.

Just to avoid potential confusion: "individually" is likely the wrong word to use.
You can update multiple attributes at the same time, within the same PATCH request (i.e. you don't have to issue separate request for each attribute).

(07-21-2017, 09:37 AM)natanfelles Wrote: But, as I understand it, the PUT is used to replace the entire entity.

Yes, it is the equivalent of a REPLACE statement in an SQL database. And it's not just a full update - it will replace the entire resource if it exists, or create it if it doesn't exist.

(07-21-2017, 09:37 AM)natanfelles Wrote: I saw in most of the documentation recommending the use of PUT as the default for updating, but studying the difference between PUT and PATCH I had this doubt.

I don't know if you're talking about CI4 documentation, or something else, but that's probably just because implementing PUT is easier.

(07-21-2017, 04:37 PM)skunkbad Wrote: Flexible != Rigid REST API.

If you want flexible, GET and POST all the way home.

I have to disagree.

You are right to an extent that POST is "flexible" on its own, as you can do anything with it, but that doesn't mean it provides for a flexible API.

You'll need good API design skills (and design is hard) to produce a sane RESTful API, but it is the rigid simplicity that makes REST very flexible.
Shoe-horning everything into GET and POST is a common thing only because of how browsers and HTML forms work. You can get away with that when you only need a current version of your app to work, but that is a luxury that you don't have when building APIs and it turns into a maintenance hell.

Read up on what "idempotency" means and you should know what I mean. Smile

(07-22-2017, 09:11 PM)ciadmin Wrote: It is my understanding that PATCH, while "more correct", is not used instead of POST because of the ACTION attribute of an HTML form.

Within a regular, browser-facing web appliation - yes.
But it's also because PATCH is actually an extension to the HTTP protocol, not part of the base specification.

RFC 7231 defines the baseline request methods.
RFC 5789 defines the PATCH attribute as an extension to the HTTP/1.1 standard.

(the second one has a higher RFC number as the original HTTP/1.1 spec was RFC 2616, but that was later re-issued as multiple RFCs)
Reply
#12

(07-24-2017, 12:17 AM)Narf Wrote:
(07-21-2017, 04:37 PM)skunkbad Wrote: Flexible != Rigid REST API.

If you want flexible, GET and POST all the way home.

I have to disagree.

You are right to an extent that POST is "flexible" on its own, as you can do anything with it, but that doesn't mean it provides for a flexible API.

You'll need good API design skills (and design is hard) to produce a sane RESTful API, but it is the rigid simplicity that makes REST very flexible.
Shoe-horning everything into GET and POST is a common thing only because of how browsers and HTML forms work. You can get away with that when you only need a current version of your app to work, but that is a luxury that you don't have when building APIs and it turns into a maintenance hell.

Read up on what "idempotency" means and you should know what I mean. Smile

I'm pretty sure most of the APIs I've used were designed by either idiots or computer scientists that are so advanced they can no longer speak to other humans.

I did look up "idempotency", and it seems like something that I already expect for certain requests.

I'd like to see some examples of these sane RESTful APIs you speak of. Do you have any favorites?
Reply
#13

(07-24-2017, 01:50 PM)skunkbad Wrote: I'm pretty sure most of the APIs I've used were designed by either idiots or computer scientists that are so advanced they can no longer speak to other humans.

I did look up "idempotency", and it seems like something that I already expect for certain requests.

I'd like to see some examples of these sane RESTful APIs you speak of. Do you have any favorites?

GitHub's is a widely praised one, but it has a LOT of endpoints, so it is easy to get lost in it. Unfortunately, I don't have other public examples. :/
Reply




Theme © iAndrew 2016 - Forum software by © MyBB