How do PUT, POST or PATCH request differ ultimately?

Question

The data, being sent over a PUT/PATCH/POST request, ultimately ends up in the database.

Now whether we are inserting a new resource or updating or modifying an existing one - it all depends upon the database operation being carried out.

Even if we send a POST and ultimately perform just an update in the database, it does not impact anywhere at all, isn't it?!

Hence, do they actually differ - apart from a purely conceptual point of view?

Answer 1

It is about the intent of the sender and from my perspective it has a different behaviour on the server side.

in a nutshell:

• POST : creates new data entry on the server (especially with REST)
• PUT : updates full data entry on the server (REST) or it creates a new data entry (non REST). The difference to a POST request is that the client specifies the target location on the server.
• PATCH : the client requests a partial update (Id and partial data of entry are given). The difference to PUT is that the client sends not the full data back to the server this can save bandwidth.

In general you can use any HTTP request to store data (GET, HEAD, DELETE...) but it is common practice to use POST, PUT, and PATCH for specific and standardized scenarios. Because every developer can understand it later

Answer 2

They are slightly different and they bind to different concepts of REST API (which is based on HTTP)

Just imagine that you have some Booking entity. And yo perform the following actions with resources:

POST - creates a new resource. And it is not idempotent - if you sent the same request twice -> two bookings will be stored. The third time - will create the third one. You are updating your DB with every request.

PUT - updates the full representation of a resource. It means - it replaces the booking full object with a new one. And it is idempotent - you could send a request ten times result will be the same (if a resource wasn't changed between your calls)

PATCH - updates some part of the resource. For example, your booking entity has a date property -> you update only this property. For example, replace the existing date with new date which is sent at the request.

---

However, for either of the above - who is deciding whether it is going to be a new resource creation or updating/modifying an existing one, it's the database operation or something equivalent to that which takes care of persistence

You are mixing different things.

The persistence layer and UI layer are two different things.

The general pattern used at Java - Model View Controller.

REST API has its own concept. And the DB layer has its own purpose. Keep in mind that separating the work of your application into layers is exactly high cohesion - when code is narrow-focused and does one thing and does it well.

Mainly at the answer, I posted some concepts for REST.

The main decision about what the application should do - create the new entity or update is a developer. And this kind of decision is usually done through the service layer. There are many additional factors that could be done, like transactions support, performing filtering of the data from DB, pagination, etc.

Also, it depends on how the DB layer is implemented. If JPA with HIbernate is used or with JDBC template, custom queries execution...