Clever Geek Handbook

Asp.net mvc and web api, which is better Http POST or PUT

I have an application like asp.net mvc and web api. I'm a little bit confused about http post and http put. When to use what and what are the pros and cons of each. I have gone through a lot of blogs, but not reasonably what it is for.

+3


source to share


2 answers


Use POST

wherever you have to create a completely new post from scratch. Use PUT

where you will need to update an existing record in your database

Here are the differences between PUT and POST

   `POST is Not idempotent`-->

The POST launcher will create a new instance over and over again each time the call is started.

`PUT is Idempotent`-->


PUT - An Idempotent operation calling PUT over and over will produce the same result.

So POST is not idempotent whereas PUT is idempotent.

`There is also PATCH` -->

Use a patch when you only need to update a few properties of your model. In other words, Partial Updates.

+2


source


Simply put (no pun intended):

POST

usually used to CREATE new objects.

PUT

commonly used to UPDATE existing objects

Using correct HTTP verbs allows for a cleaner API to publish and negates the need for encoding intent in the endpoint (url). For example, compare:

Using regular verbs:



GET    api/user/12345
POST   api/user/12345
PUT    api/user/12345
DELETE api/user/12345

Endpoint Hack:

GET  api/user/12345
POST api/user/12345/create
POST api/user/12345/update
POST api/user/12345/delete

I think only AGAINST using PUT

etc. this is something that not all developers are familiar with, and some third-party programs may not support them, or at least not as easy as using the more familiar verbs like GET

and POST

.

For example, I had a problem a few weeks ago where a proxy was placed in front of the API just before it was supposed to live, and the proxy did not support the verb HTTP PUT

(maybe a configuration issue, but we didn't have access to the proxy -server to fix it), so we had to tweak the API and change it to POST

last minute (which also meant we had to change the clients (mobile apps) that were using it).

0


source






More articles:


All Articles