2

PATCH is used to update partial information of an already existing resource and PUT is used to replace the old information of that resource with the new one. Now, how should this concept be implemented in AngularJS?

One probable way may be:-

At the controller, calculate the number of fields changed by the user via a form and set a threshold like 50%, i.e. if more than 50% of the form fields are updated by the user, then call $http.put or otherwise call $http.patch.

Is there any standard way to apply this concept or the above mentioned way is also in the right direction?

Sahil Babbar
  • 579
  • 1
  • 7
  • 21

2 Answers2

3

It is really up to how the API establishes the request type that should be used on each of its resources.

In an ideal world, you would:

  • Use POST to create resources on resource collections. e.g. two requests of POST /v1/cars would result in /v1/cars/1 and /v1/cars/2 being created.
  • Use PUT to update the resource attributes, ideally when all the attributes are being changed even if they are keeping the same value. The request body (payload) should include all the attributes. PUT is idempotent, meaning that if you make two requests PUT /v1/cars/1, with the same request body (payload), it will result in the car with identifier 1, updated with the attributes. N number of identical requests ends up in the same updated/modified entity representation.
  • Use PATCH to perform partial modifications on the resource. SO if you were updating just a make and model on car 1, but not the price, then PATCH is ideal here as long as the API supports it.

Ultimately, in reality, to answer your question, whoever creates the API you are using (your back end), will decide what verbs should be used for what. So In reality, you will see it all wrong in many API's, things like POST used for upserts and updates, PUT for create, POST to perform GET's, it's up to them really.

If you have control over that backend your angular.js app relies on, try to stick as close as you can to those guidelines. But those are just guidelines, they don't need to be enforced and many times your business needs requires you to divert from them. So use PATCH for partial entity updates, PUT for full entity updates, or just PATCH for everything (partial/full). You'll find what works for you. And forget about that rule of percentages you wrote in your question, that just complicate things.

I personally use PATCH as updates, either partial of full. So I don't have to support on my API's two ways of updating a resource, so I don't support PUTs. But some of my colleagues use with their teams PUT as a PATCH. So they don't support PATCH. They do Partial updates with PUT which works for them and their customers as well.

Read more on PATCH, POST, PUT

Juan
  • 6,125
  • 3
  • 30
  • 31
  • Ok, but how do you perceive the idea of computing whether its a partial change or full, on the frontend? – Sahil Babbar Jun 27 '17 at 06:11
  • 1
    You don't, if patch is supported you end up using patch and update/send just the attributes you to fulfill your business needs. At my current company, Patch is not supported, but PUT allows partial updates in our api's, so we use PUT for partial updates and we don't compute that in the front end or worry about what to send, we know what we need for each case. And we don't worry about overwriting unsent attributes with nulls etc. But really that is up to how the contracts by the API are defined. – Juan Jun 27 '17 at 15:13
0

PUT is used to create, POST to update see PUT vs POST in REST

You could use PATCH for very specific update for instance, if some information about a resource is cached and the other is not, you could used PATCH and PUT separately as a clear way to distinct which one will cause a cache refresh.

Another way to think this would be for a update of a complex resource that has relations with others resources.

PATCH could be used to add relations to existing ones while POST would overwrite the whole list.

To be honest I usually use PUT to create but I don't allow overwriting of existing entites with PUT, only POST to update.

I am basically following only partially HTTP because :

  • Even if it is only partial, someone seeing the usage of PUT/POST/GET will expect it to do the corresponding operation. It make my code more readable.
  • Implement it fully may take quite some time for no benefit for what I am doing.
  • Usually in UI of what I do, creating and modifying are part of 2 separates screen with different rights, having two separates method+URL makes possible to apply rights restriction to each of them separately by configuration only and not by code. Note that if you use POST xxx to create and POST xxx/[id] to update you have two differents URL.
Walfrat
  • 5,363
  • 1
  • 16
  • 35
  • I've always thought of PATCH as appropriate when you are sending only a set of changes, PUT and POST when you're sending the full entity. In the past, for example, I worked on a project where we used PATCH for all updates as we had a security model that meant we weren't sending all fields to the client in most cases. It was always technically a delta. – Matt Holland Jun 26 '17 at 20:27
  • @MattHolland That's effectively the whole point, I was trying to figures out some proper example for that. Considering that except insert-only field I always send whole objects, I have no use for PATCH myself. – Walfrat Jun 26 '17 at 20:29
  • The difference between PUT and POST is that PUT is idempotent. Multiple PUT requests with the same payload result in the same updated entity opposed to POST where multiple POST requests would result on multiple side effects like multiple entries created. I wouldn't state or advice POST is good for updates. PATCH/PUT are the ones for the job. All the above, if you were to follow what each verb/request is meant to be used for as ultimately, in reality, you can have those requests do whatever: Like POST doing updates. – Juan Jun 26 '17 at 20:34
  • 1
    POST is to create and PUT and PATCH are for updating. PUT is idempotent, POST is not. PUT must NOT be used to create a resource. PATCH is used to do a partial update of a resource. PUT always replaces the resource in its entirety. Please don't mix these up. – Joshua Jones Jun 26 '17 at 23:22
  • @Walfrat the question doesn't ask about the difference between HTTP verbs. But would like to know the whether the idea of using PATCH or PUT by computing it on the frontend, is feasible in terms of scalability or not. – Sahil Babbar Jun 27 '17 at 06:14
  • 1
    @SahilBabbar The scalability isn't mentioned in your question, and I don't see anything that would need a distinction between PUT and PATCH for scalability, except for some micro-optimisation that even for SO may not be needed. – Walfrat Jun 27 '17 at 07:41