REST: Should PUT endpoint compare the GET response before updating?

Viewed 435

I am developing a REST API in Spring boot and i am trying to understand the PUT action. Currently my PUT action takes the object id and checks if the object is present and then replaced the object with the new one. I have the following questions.

  1. Should i compare the old object with the new one before saving the new one to know if the newobject is modified at all and return an approriate http response status if the object is unchanged ?
  2. If i do want to compare, what is the best way to know if the object is really modified or not

Thanks.

3 Answers

No, you don't need to compare generally. PUT means you need to replace all the values with new ones, but if you need to keep the created by or created time properties you should get the record from db and update necessary values form previous record to new one.

If you need to compare two objects you need to override equal and hashCode method. then you can check a.equal(b) to check whether values are changed. Keep in mind if object contains datatime or random generation numbers avoid adding them inside equal method.

PATCH is where you need to get the current record from db and update relevant values.

You can decide between PUT or PATCH, not all protocol support PATCH.

When a client needs to replace an existing Resource entirely, they can use PUT. When they’re doing a partial update, they can use HTTP PATCH.

if you are using PUT there you need to do all compare things and check for example:

  1. Get Object from DB

  2. check and update whatever is updated business object

  3. then save. to answer your question, object is modified is not required you to compare value from existing object and new object.

but if client side OK to send only updated properties then PATCH is better to use.

to know more and how you can implement, please blog

HTTP PUT vs HTTP PATCH in a REST API

REST: Should PUT endpoint compare the GET response before updating?

Neither REST nor HTTP put any particular constraints on the implementation - only the semantics are constrained. RFC 7231

HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent of the user agent request and the semantics of the origin server response.... Generally speaking, all implementation details behind the resource interface are intentionally hidden by the server.

RFC 7232 might have a clue to what you are looking for

An origin server MUST NOT perform the requested method if a received If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the 412 (Precondition Failed) status code or b) one of the 2xx (Successful) status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent).

So as far as the spec is concerned, you can pretend that you changed things, even though a no-op was equivalent to what the client asked for.

If i do want to compare, what is the best way to know if the object is really modified or not

Not enough information provided. That's going to depend on things like how the origin server stores resource state. If you are just dealing with raw documents, then comparing two long hash keys could be fine.

Related