Mise à jour d'une ressource via REST (PUT/POST)

Question

Lors de la mise à jour d'une ressource via REST, faut-il inclure dans le corps uniquement les valeurs à mettre à jour ou l'objet entier (valeurs actuelles et valeurs à mettre à jour)?

Si un objet utilisateur ressemble à ceci

User (id, name, age, sex) 

et je veux mettre à jour que son nom et son âge, si ma demande ressembler à ceci:

PUT /users/1 

{"name":"john","age":18} 

ou comme ceci:

PUT /users/1 

{"name":"john","age":18, "sex":"m"} 

Et à quoi cela devrait-il ressembler sur le serveur s ide?

@RequestMapping(value = "/{userId}", method = PUT, consumes = MediaType.APPLICATION_JSON_VALUE) 
public ResponseEntity<String> updateUser(@PathVariable final int userId, @RequestBody User u){ 
    //fetch user by ID 
    user.setName(u.getName()) 
    user.setAge(u.getAge()) 
    user.setSex(u.getSex()) //this will be empty? 

    return new ResponseEntity<String>(gson.toJson(user), HttpStatus.OK); 
} 

Ou bien je pourrais trouver sur les variables ne sont pas incluses dans le corps de la demande et de faire quelque chose comme ça

if(u.getName()!=null){ 
    user.setName(u.getName()) 
} 
if(u.getAge()!=null){ 
    user.setAge(u.getAge()) 
} 
if(u.getSex()!=null){ 
    user.setSex(u.getSex()) 
} 

Est-il possible de bien/mal pour y parvenir, ou est-ce un cas de faire juste ce qui est le plus facile?

Answer 1

PUT Les requêtes doivent être idempotentes et doivent fournir comme charge utile une représentation complète de l'entité qu'elles remplacent. (https://tools.ietf.org/html/rfc7231#section-4.3.4)

La méthode PUT demande que l'état de la ressource cible soit créé ou remplacé par l'état défini par la représentation enfermé dans la charge utile du message de demande.

Un objet JSON partiel PUT demande serait un PATCH avec Content-Type: application/merge-patch+json (https://tools.ietf.org/html/rfc7396)

choses à penser. Vous pourriez avoir plusieurs clients mettant à jour une entité en même temps, en utilisant un PUT pourrait finir par écraser les changements que d'autres clients ont faits.

Dans ce cas, vous pouvez définir un pre-condition pour vérifier si l'objet a été mis à jour entre le moment où le client demandeur a récupéré l'entité, a apporté des modifications et a soumis la demande PUT/PATCH. Par exemple, la pré-condition peut être un dernier horodatage mis à jour, hash (Etag) ou un numéro de version; Ou vous pouvez utiliser une approche de «dernière écriture gagne» qui est commune dans les systèmes finalement compatibles. Tout dépend de votre système et de la situation. Du côté serveur, si vous prenez en charge les mises à jour partielles, comme vous l'avez indiqué dans votre exemple, vous identifieriez l'ensemble des propriétés incluses dans la requête et ne définiriez que celles spécifiques qui ont été fournies.