28
loading...
This website collects cookies to deliver better user experience
PUT
vs PATCH
. You might be thinking, "Oh yeah, that's a common interview question!" But you know what, as common as you think it is, I actually didn't know how to answer this question (and yep, got rejected too haha🥲). Now I learned my lesson, I decided to write an article not only to help myself to understand but for those who are preparing for your (next) interviews! Create
in CRUD
201 (CREATED)
and return a location-header with a link, like https://www.example.com/recipes/1
.POST
requests will result in two different resources containing the same informationconst axios = require('axios')
axios.post('https:sample-endpoint.com/user', {
Name: 'Fred',
Age: '23'
})
.then(function (response) {
console.log(response);
})
Update
in CRUD
200 (OK)
, or 204 (No Content)
if nothing is updated. If successfully created, will return the HTTP status code 201 (CREATED)
.const article = { title: 'React PUT Request Example' };
axios.put('https://reqres.in/api/articles/1', article)
.then(response => this.setState({ updatedAt: response.data.updatedAt }));
Update
in CRUD
200 (OK)
, or 204 (No Content)
if nothing is updated.const res = await axios.patch('https://httpbin.org/patch', 'hello=world');
res.data.headers['Content-Type']; // application/x-www-form-urlencoded
res.data.json; // { hello: 'world' }
PUT
can both create and modify a resource while POST
can only create a resource.PUT
, if the Request-URI refers to an already existing resource, an update operation will happen, otherwise, it will create a new resource IF the Request-URI is a valid resource URI.The request URI is the uniform resource identifier of the resource to which the request applies. While URIs can theoretically refer to either uniform resource locators (URLs) or uniform resource names (URNs), at the present time a URI is almost always an HTTP URL that follows the standard syntax rules of Web URLs.
PUT /users/{user-id}
POST
, the origin server accept a request as a new subordinate of the resource identified by the Request-URI.POST /users
PUT
method is idempotent. Meaning if you (re)try to send a request multiple times, this is equivalent to a single request modification. POST
method is NOT idempotent. If you retry to send a request multiple times, you will end up having multiple resources with multiple different URIs on the server.PUT
method is used for UPDATE
operations while the POST
method is used for the CREATE
operations.PUT
and PATCH
can both be used for updating resources. However, the biggest difference between these two is that one can update and replace the resource while the other one can update partially.PUT
request, the enclosed entity (a specific place you are making request on) is viewed as the modified version of the resource, and the client is requesting to replace with the new info; when making a PATCH
request, it modifies only some part of the resource.// House on plot 1
{
address: 'plot 1',
owner: 'segun',
type: 'duplex',
color: 'green',
rooms: '5',
kitchens: '1',
windows: 20
}
PUT
// PUT request payload to update windows of House on plot 1
{
address: 'plot 1',
owner: 'segun',
type: 'duplex',
color: 'green',
rooms: '5',
kitchens: '1',
windows: 21
}
PATCH
// Patch request payload to update windows on the House
{
windows: 21
}
PUT
is idempotent with reasons mentioned above, while PATCH
is not idempotent. If a request is reattempted to be made, it will result a failed request (Method Not Allowed)
. If a PATCH
request is made to a non-existent URI, it would simply fail without creating a new resource like PUT
. PUT
vs POST
: YAS to creating new resources, but only PUT
can update/modify resources and it is idempotent but not for POST
PUT
vs PATCH
: YAS to modify/update resources. PATCH
allows us to modify the enclosed entity partially, while PUT
basically replaces the entire thing.