0

What's the best practice around updating information received from the request?

  1. Update all the columns with the values received in the request object? What if there are columns that should be updated when posted by admin and not by the regular user? We have a lot of such situations.

  2. Should the backend check what attributes are getting a different value from what is saved in the DB?

P.S: We are using Dynamo and AWS API gateway and this is a serverless application

1

A PUT request always places one thing in the service.

You need to decide what that one thing is. Two of the choices are:

  • The thing is a specific property, and the system has ways of selecting sets of properties.
  • The thing is a specific object with a number of properties.

If you select one path, you can easily PUT new properties independently, at the cost of doing many puts when you have many properties to update. There is a risk in this approach, as in a collection of operations, you'll need to monitor and manage every operation was succesfully executed.

If you select the other pat, you can easily PUT new objects, which will always be consistently placed with all properties at the new correct value.

A PATCH request modifies an existing thing

The HTML PATCH verb is a relatively new construct. In this approach, you operate like a PUT, but you only include the portions of the object that have new values. The server receives this request, and will merge the existing object with the request. Typically this is done by locating JSON node above the value, and replacing the node with the new value. For example

 Person: {
    Age: 5,
    Height: 30,
    Hobbies: [ 'crayons', 'dancing', 'singing' ]
 }

would only replace the Person.Age, Person.Height, and Person.Hobbies values, even if there are also Person.Name, Person.Weight, and Person.Gender properties already in the object at that URL.

8
  • Thanks for your response. What if there are columns that should be updated when posted by admin and not by the regular user? We have a lot of such situations so adding if /else for each of those does not sound like a good idea and I would not want to create an endpoint for each attribute update – S Khurana Apr 8 at 23:58
  • Then you need to make the PATCH method check that the current session's user has the authority to change the field, and return an Unauthorized response (401), while not updating anything, if they change a field they shouldn't. Typically I like to make the ID not changeable, because it shouldn't be submitted with the wrong value at the same URL, and a PATCH on it at the new URL doesn't have a correct object to work on. – Edwin Buck Apr 9 at 0:06
  • 1
    @SKhurana A session doesn't really exist in any HTTP framework, it is simulated by the client passing in some data to the server which is sufficient enough for the server to realize this request is associated with previous requests. What does exist is the idea of a session, and in your case, the JWT tokens either contain the user information or can be used to lookup the user that obtained the token. – Edwin Buck Apr 9 at 0:16
  • 1
    @SKhurana There's a million ways to write that if/else statement (should you even use an if/else statement) and while it is a serverless application, it's not a logic-less application. You'll have to pick a way that suits your needs and go with it. You'll just not be able to count on the data in RAM to make the decision. Odds are you service will query the database twice. Once to collect the data about the object to be patched, and once to collect the data about the rules permitting or denying users (or groups of users) to patch the various items in the object. – Edwin Buck Apr 9 at 0:28
  • 2
    This is not really how PATCH is supposed to work. The message body for a PATCH request is a diff that is to be applied to the object, not a partial representation. A real diff makes it possible to e.g. add elements to a collection without having to re-iterate all the other elements. – marstato Apr 9 at 10:16
1

What's the best practice around updating information received from the request?

What a PUT message means (semantics): replace the representation of the target resource with the representation in the message-body of the request.

What the server should do when it receives a request to replace the representation of the target resource? Whatever you think is best.

An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT.... When a PUT representation is inconsistent with the target resource, the origin server SHOULD either make them consistent, by transforming the representation or changing the resource configuration, or respond with an appropriate error message containing sufficient information to explain why the representation is unsuitable. -- RFC 7231

So it is completely in bounds to make changes that are not an exact match with what the request asks for. You need to be a little bit careful with your response not to imply that you've accepted the representation as is when in fact you've made some changes to it.

How the server actually makes the change is beyond the scope of PUT; HTTP gives us a shared understanding for what the message means, but implementations are free to do what they like with the message.

Therefore: pulling out your server's representation, selectively making changes, and then saving your result is fine (from the perspective of REST/HTTP).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.