4

I am working on a restful api and I need to update a resource (i.e. a customer detail record with 10 fields).

On Add request, I send a Post request with complete record. On update request, I send a PUT request with complete record of 10 fields. On Verify request, I send a PUT request with just two fields i.e. recordId and versionNo. On Delete request, I send a DELETE request with two fields in HttpOptions.

I have few questions that:

  • Although, it a restful api but specific application which would be used by an angular application, So should I return data in response of POST/PUT requests.

  • Should I use PATCH in case of Verify (or anyother action where just recordId and versionNo send to server to change some fields) or it is OK to use PUT.

  • To make uniformity, should I send data in body of delete request as I need recordId and versionNo to delete a record.

TAB
  • 1,944
  • 8
  • 28
  • 45

2 Answers2

8

Should I use PATCH in case of Verify (or anyother action where just recordId and versionNo send to server to change some fields) or it is OK to use PUT.

In RESTful API designs, PUT requests are generally used to add or replace an entire resource, whereas a PATCH should be just used to update an existing resource. A PUT request is called "idempotent" - no matter how many times you send a PUT response, you should get the same result. A PATCH is not idempotent.

example:

PATCH /Cars/vauxhall-astra/engine --> This request would be used to only update the engine of my already existing vauxhall astra

PUT /Cars/renault-clio --> This request would create a new Renault Clio or, if it already exists, replace the entire Clio using the data specified in my request. A Clio would then be guaranteed to exist after my request is successful, regardless of whether it existed or not before.

Although, it a restful api but specific application which would be used by an angular application, So should I return data in response of POST/PUT requests.

Totally up to you, returning data from a POST/PUT is fine - especially if it saves you having to make extra GET api requests. Just always make sure you are only ever returning the data you need from a response.

To make uniformity, should I send data in body of delete request as I need recordId and versionNo to delete a record.

Again it's totally up to you. Whether you use query parameters (e.g. DELETE cars?id=123) or a request body is just your preference, there's nothing in REST that has rules for this.

J Marlow
  • 744
  • 1
  • 5
  • 11
  • PATCH is not idempotent. Does it mean, when a PATCH request is made, api update it iff the resource exists. If resource doesn't exist, it will not update the resource. – TAB Feb 25 '19 at 12:03
  • Yes that's correct. Remember that idempotency means the same request should always produce the same result. A PATCH cannot be idempotent, because imagine you send a PATCH request that changes the location of a resource. If you sent through the exact same PATCH request through again it would fail because the location has since changed. – J Marlow Feb 25 '19 at 12:17
  • In my case, a PATCH request only be made when a record exists and a verify action is available. So in this scenario, it would be safe to use PATCH, instead of PUT, while I just need to update statusCode of that particular record. – TAB Feb 25 '19 at 13:13
  • Yeah, you should use PATCH in this situation – J Marlow Feb 25 '19 at 13:20
2

REST Response

A RESTful API MUST always answer with HTTP codes to client requests:

Success and error responses are a vital part to define how an API is used correctly.

Refer to this guide to solve all your RESTful related questions.

PATCH/PUT

From Wikipedia:

The main difference between the PUT and PATCH method is that the PUT method uses the request URI to supply a modified version of the requested resource which replaces the original version of the resource whereas the PATCH method supplies a set of instructions to modify the resource. If the PATCH document is larger than the size of the new version of the resource sent by the PUT method then the PUT method is preferred.

Also:

Using the PUT method consumes more bandwidth as compared to the PATCH method when only a few changes need to be applied to a resource. But when the PATCH method is used, it usually involves fetching the resource from the server, comparing the original and new files, creating and sending a diff file. On the server side, the server has to read the diff file and make the modifications. This involves a lot of overhead compared to the PUT method.[11] On the other hand, the PUT method requires a GET to be performed before the PUT and it is difficult to ensure that the resource is not modified between the GET and PUT requests.

So I will use PATCH for verifying a resource.

DELETE

Normaly, for DELETE requests, the client specifies the id of the resource and pass it ass a Path Variable on the URL:

curl -X DELETE http://example.com/resource/{id}

But you can pass a body on the request also. This possibility is stated by MDN Mozilla Web DOCS:

Request has body - May

Successful response has body - May

Community
  • 1
  • 1
Victor Calatramas
  • 803
  • 6
  • 15