CODEWITHSUNDEEP
springspring-bootrestpatch
Gutter Overflow
Gutter Overflow

Reputation: 149

What is the point of having PATCH, POST, PUT types when we use repository save methods for all?

As a newcomer to spring I would like to know the actual difference between:-

@PostMapping
@PutMapping
@PatchMapping

My understanding is PUT is for update but then we have to get the element by its id and then save() it. Similarly the save() method is again used by Post which automatically replaces by its identifier(PRIMARY). In my application I am able to use three of these methods interchangeably.

Upvotes: 2

Views: 1299

Answers (2)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57367

What is the point of having PATCH, POST, PUT types when we use repository save methods for all?

HTTP method tokens are used to define request semantics in such a way that general purpose components (browsers, reverse proxies, etc) can exploit the information to do intelligent things.

The easiest of these is that PUT has idempotent semantics; if an http response is lost, a general purpose component knows that it may autonomously retry sending the request. This in turn gives you a bit of extra reliability over an unreliable network, "for free".

The fact that your origin server uses the same persistence mechanism for each is an implementation detail, something deliberately hidden behind the "uniform interface".

The difference between PATCH and POST is subtle; PATCH gives you an unambiguous way to designate that the enclosed entity is a patch document, and offers a mechanism for discovering which patch document formats are understood by the origin server, neither of which you get from POST alone.

What's less clear, at least to me, is whether PATCH semantics allow an intermediate component to do something intelligent with a request - in other words, do the additional constraints (relative to POST) allow intermediaries to do anything interesting?

As best I can tell, the semantics of a PATCH request are more specific, but not actionably more specific -- certainly not as obviously as we have in the case of safe or idempotent request semantics.

Upvotes: 2

deRailed
deRailed

Reputation: 579

POST is for creating a brand new object.

PUT will replace all of an objects properties in one go.
Leaving a property empty will empty the value in the datastore.

PATCH does a partial update of an object. You can send it just the properties which should be updated. A PATCH request with all object properties included will have the same effect as a POST request. But they are not the same.

The HTTP method is a convention not specific to Spring but is a main pillar of the REST API specification.

They make sure the intent of a request is clear and both the provider and consumer are in agreement of the end result.
Kind of like the pedals or gear shift in our cars. It's a lot easier when they all work the same.
Switching them up could lead to a lot of accidents.

For us as developers, it means we can expect most REST APIs to behave in a similar way, assuming an API is implemented according to or reasonably close to the specification.

POST/PUT/PATCH may look alike but there are subtle differences. As you mention the PUT and PATCH methods require some kind of ID of the object to be updated.

In an example of a combined POST/PUT/PATCH endpoint, sending a request with an object, omitting some of its properties. How does the API react?

  1. Update only the received properties.
  2. Update the entire object, emptying the omitted properties.
  3. Attempt to create a new object.

How is the consumer of the endpoint to know which of the three actions the server took?

This is where the HTTP method and specification/convention help determine the appropriate course of action.

Spring may facilitate the save method which can handle both creation, updates and partial updates. But this is not necessarily the case for other frameworks in Java or other languages.

Also, your application may be simple enough to handle POST/PUT/PATCH in the same controller method right now. But over time as your application grows more complex, the separation of concerns makes your code a lot cleaner, more readable and maintainable.

Upvotes: 1

Related Questions