[natanfelles]

Assuming that PATCH makes it possible to update one attribute at a time while the PUT forces the update of the entire entity.

Is not more versatile the default Update route for Resource be a PATCH method? Why?

[Narf]

Assuming that PATCH makes it possible to update one attribute at a time

Wrong assumption. You can update as many attributes as you want.

[natanfelles]

Assuming that PATCH makes it possible to update one attribute at a time

Wrong assumption. You can update as many attributes as you want.

No. Yes, with PATCH you can update as many attributes as you need individually. But, as I understand it, the PUT is used to replace the entire entity.

I believe that PATCH makes the application more flexible because it does not "force" the client to send all the attributes to be updated, but only what is necessary.

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.

Here are some opinions and examples to take into consideration: https://stackoverflow.com/questions/2845...e-examples

[skunkbad]

I believe that PATCH makes the application more flexible...

Flexible != Rigid REST API.

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

https://www.youtube.com/watch?v=WO23WBji_Z0

[natanfelles]

I believe that PATCH makes the application more flexible...

Flexible != Rigid REST API.

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

https://www.youtube.com/watch?v=WO23WBji_Z0

Ok. Then is used PUT by default to the system be rigid. Now I think that I understand why this is the default verb in the Resource Routes.

https://www.youtube.com/watch?v=Y_2VchV2rUs

[kilishan]

I guess my knowledge was simply based on old practices. Reading back through RFC7231 and RFC5789 it appears you are correct.

The difference between the PUT and PATCH requests is reflected in the
  way the server processes the enclosed entity to modify the resource
  identified by the Request-URI.  In a PUT request, the enclosed entity
  is considered to be a modified version of the resource stored on the
  origin server, and the client is requesting that the stored version
  be replaced.

To the best of my knowledge those are the two most current versions of the relevant RFCs. So, yes, PATCH should be the default. In the end, it doesn't really matter because it's all in how you code your application to behave, anyway To be correct, though, we should probably change that.

[ciadmin]

It is my understanding that PATCH, while "more correct", is not used instead of POST because of the ACTION attribute of an HTML form. The only way to generate a PATCH would be through an AJAX request

[natanfelles]

It is my understanding that PATCH, while "more correct", is not used instead of POST because of the ACTION attribute of an HTML form. The only way to generate a PATCH would be through an AJAX request

Yes. But I'm referring to Resource Routes.

[ciadmin]

It is my understanding that PATCH, while "more correct", is not used instead of POST because of the ACTION attribute of an HTML form. The only way to generate a PATCH would be through an AJAX request

Yes. But I'm referring to Resource Routes.

Good point

[natanfelles]

Explaning more...

If you have a "product" entity with the following attributes:

- id
- title
- short_description
- description
- price
- stock
- uri
- rate
- bla

Every time that you need to update it. The PUT "forces" you to send all the attributes because have the function of REPLACE the entire entity. Then, if you need update ONLY the price attribute, you need to send ALL the other attributes.

The PATCH method enables you to send ONLY the price attribute. It is more flexible, save bandwidth traffic data and processing.

I read the GitHub REST API docs and see that it uses PATCH. I did some research and thought, "Why is PUT the default update verb in CI?"... And here is the question...

This change is only in the HTTP verb of Update. With a HTML form request nothing changes, continues to be with POST.

* I thought, originally, in Portuguese, Hahah.