what does @PatchMapping do
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.