1

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?

Fabricio Rodriguez
  • 3,769
  • 11
  • 48
  • 101

2 Answers2

1

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!

Community
  • 1
  • 1
Lorenzo Isidori
  • 1,809
  • 2
  • 20
  • 31
  • 2
    Please stop using the old and long outdated RFC 2616 as reference. It was replaced by a new set of RFCs: 7230-35. – cassiomolin Sep 12 '18 at 10:04
  • Ok, maybe you can suggest us the new link. Anyway the sake of the answer doesn't deserve a down vote for that. – Lorenzo Isidori Sep 12 '18 at 10:06
  • Thanks for the link Cassio. Interesting that it says POST is to "Perform resource-specific processing on the request payload". It doesn't specifically mention INSERTING. So perhaps from that point of view, a POST would be appropriate in this case, as I am asking the API to "process the provided payload". – Fabricio Rodriguez Sep 12 '18 at 13:13
-1

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

Sheetal Mohan Sharma
  • 2,908
  • 1
  • 23
  • 24
  • 1
    POST usually creates resources and PUT updates though both can perform the other too. POST is an all purpose operation that should be used if none of the other method is expressive enough. PUT i.e. is also allowed to have side effects. While safetiness is an important promiss to clients which do not want to alter data (i.e. web crawlers), if you need to persist stuff this is rather an unimportant feature. In order to stay in the semantics of PATCH the client needs to calculate the necessary changes beforehand and send them as atomic instruction to the server - either all succeed or none at all – Roman Vottner Sep 12 '18 at 11:22
  • [Suggested reading](https://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/) – Roman Vottner Sep 12 '18 at 11:23