There is a RequestMethod named PATCH.
To use this method, we can define @PatchMapping for a rest endpoint. As per my understanding, it sounds like partially updating the DB object.
Generally, we use POST or PUT calls to perform save or update. So, still not clear what are exact use cases of PatchMapping and why can't I just use PUT instead of PATCH?
still not clear what are exact use cases of PatchMapping and why can't I just use PUT instead of PATCH?
PUT (defined by RFC 7231) and PATCH (defined by RFC 5789) are two different methods used for a similar purpose: to request that the server make its representation of a resource match the representation on the client.
Imagine, if you would, trying to update a web page provided by a server. The client first obtains a recent copy of the server's representation:
GET /foo
and then, using the client's favorite local HTML editor, makes changes to this private copy. When the client has finished making the changes, we want to send those changes back to the server to be used.
The straight forward way to do this in HTTP is to simply send the entire updated representation back to the server:
PUT /foo
<html>....</html>
When the representation is very large (compared with the HTTP headers), and the edits are very small (compared to the document), then PUT becomes a somewhat "expensive" way to achieve what ought to be a small thing.
To that end, we might also support PATCH, so that instead of sending the entire document, we just send a representation of the changes we made: a patch document.
When the server receives our patch, it loads its own copy of the document, applies the changes described by the patch document, and saves the result.
Thus: the overall use case is the same: remote authoring. You load a representation of a resource into your HTTP aware document editor, make a few changes, and hit "save", and your editor knows what to do to communicate your edits back to the server.