Reputation: 4249
I have a RESTful Web API (written in ASP .Net Core 2.1) which receives a "change-log" from the consuming client app. This is a JSON class containing all the modifications to the database that were performed on the client app while it was working in offline mode. Once the client app goes online, it synchronizes its database with an online/live database by sending the API all the changes that have happened since the last sync. So it sends the API a change-set/change-log with a bunch of UPDATE, INSERT and DELETE lists for the various tables/objects.
On the API side, I don't actually delete anything from the live database - I simply flag things as deleted (so I set a boolean field to true, i.e. deleted
= true). So technically, the API only performs INSERTS and UPDATES on the database.
Now I am at odds on how the consuming client should call this "synchronize" endpoint of the API. Should it call it as a POST or as a PUT request? Since the API is actually performing both UPDATES and INSERTS... Which HTTP verb is more appropriate? Does it even matter?
Upvotes: 1
Views: 2331
Reputation: 2047
I can tell you my experience. The verb meanings in rest are clear and can't be misunderstood. But it doesn't cover all cases.
Usually I use PUT just for entity update, as defined. To cover all others hybrid operation I use POST.
So the PUT api are fair and clean and when you encounter a POST, it's better you dig a little bit more!
Upvotes: 1
Reputation: 2924
It's more of a convection and as per convention you have a case for POST as you are doing reconciliation. It's recommended to use PUT to create resources, or use POST to update resources.
Another things to consider is that both PUT and POST are both unsafe methods. However, PUT is idempotent, while POST is not.
Why not use use PATCH
From my bookmarks - PUT vs. POST in REST and REST API - PUT vs PATCH with real life examples
Upvotes: -1