Provide individual update of items in a resource

[jnanic]

Currently, PUT for all of the resources require all the member fields of the resources to be sent in the request. This might be problematic while API consumption also might make the update faster.

Fix it so that only member fields that need to be changed are required to be sent through the request. Or at least reduce the number of update statements by checking if the field is changed from previous value or not.

[jnanic]

The issue is of PATCH vs PUT. Need to talk to the front end team if they need both. For making the API future-proof both PATCH and PUT should be included.
@nathankurt @HarrisonSanders Thoughts?

[nathankurt]

I think PUT is definitely easier and safer to use based on looking at a few things, but I'm not too sure the difference exactly. Is patch just faster? I thought PUT also grabs the file and looks for differences there too?

[jnanic]

No. PUT changes each and every data member of the resource. In a sense, you're recreating that resource.
While PATCH only changes the required fields.
PATCH is definitely faster as it transfers only the changed data attributes and uses less bandwidth.
Ex. for resource A there are B,C,D data members. Now if you want to update value of C then PUT request would something like this

PUT url/to/the/resource/A
{
B = old_value
C = new_value
D = old_value
}

While PATCH would look something like this
PATCH url/to/the/resource/A
{
C = new_value
}

[jnanic]

PUT is not supposed to look for changes. That's how the PUT defination is defined (although you decide how you want to implement the PUT)
So, typically, if you do a PUT request and do not give all the data memebers then you lose data.
Ex. From last example if you do a PUT like this.
PUT url/to/the/resource/A
{
C = new_value
}
Then B and D become null. Again that's by the defination of PUT. It totally depends on your implementation.
In our API if all the data members are not present in the request then the API throws a 422 error.

[nathankurt]

hmmm alright, I guess that could be good especially for json. For xml(which we probably aren't using anyways) that looks like it could be a mess haha.

If you want to implement PATCH, go ahead if you have other blockers currently. But if you don't I don't think it's a huge deal.

[jnanic]

Nope. We ain't using xml. That's old tech man haha.

What do you mean by blockers lol?

[jnanic]

And I think having PATCH really makes the API future proof!

[nathankurt]

blockers as in things stopping you from doing other things. So if you have time to do it, go ahead and add it. But if there are higher priority thigns on the list, finish those first.