PATCH et rfc7396

Bonjour,

Je cherche à implémenter un service REST PATCH en JAVA, qui respecte la rfc7396 (https://tools.ietf.org/html/rfc7396 ).

Cette rfc définit que si on a un objet défini comme ceci:

Code:

---

1 2 3 4 5 6 7

{ "a": "b", "c": { "d": "e", "f": "g" } }

---

Alors on peut modifier le champ a et supprimer le champ f, sans toucher à la valeur des autres champs, en envoyant ce json:

Code:

---

1 2 3 4 5 6

{ "a":"z", "c": { "f": null } }

---

On peut donc remarquer que:

• Si le champ est absent dans le json, aucune modification n'est effectuée
• Si le champ est présent dans le json mais null, la valeur champ est supprimée
• Si le champ est présent dans le json et non null, la valeur du champ est remplacée

Seulement voilà, lors de la déserialisation du json, on perd la différence entre l'absence de la valeur dans le json et sa présence en null. Dans les deux cas, la valeur attribuée au champ de l'objet java est null.
J'utilise la balise @RequestBody avec un dto représentant mon json complet pour effectuer cette déserialisation, comme utilisée ici: https://www.baeldung.com/http-put-pa...ference-spring

J'ai trouvé une solution, qui consiste à passer tous les champs java du dto au type Optional<T>, comme garretwilson ici https://github.com/FasterXML/jackson...ment-385266611
Émettons que l'on ait un champ Optional<String> toto dans le dto, alors lors de la déserialisation, on a:

• Si le champ est absent dans le json, toto est null
• Si le champ est présent dans le json mais null, toto n'est pas null mais est vide
• Si le champ est présent dans le json et non null, toto n'est pas null et contient la valeur du champ

C'est pas mal car on peut faire la différence entre l'absence du json et la présence null, mais on se retrouve avec un objet de type Optional<T> pouvant être null, ce qui est une mauvaise pratique. 8O

Comment auriez-vous fait? Connaissez-vous une manière plus propre de procéder?

Merci pour votre aide :oops:

Je vais vous faire un petit retour sur la solution mise en place

Finalement, il est nécessaire de n'effacer que les champs String et ça simplifie bien les choses.
Au lieu d'envoyer null, on peut envoyer une chaine de caractères vide:

Code:

---

1 2 3

{ "a":"" }

---

La chaine de caractère n'étant pas null, le Java la récupère bien.
La chaîne étant vide, la base de donnée vide la valeur.

Ouf! :roll:

Je laisse le sujet ouvert, au cas où quelqu'un trouve une solution plus universelle, notamment pour les Boolean et les nombres.

Salut,

Ta solution ne respecte pas la RFC du coup... Personnellement, j'opterais pour l'une de ces trois solutions:

1. pas de désérialization en objet, juste du streaming, ce qui limiterait l'empreinte mémoire en cas de "gros" json, avec toute fois une grosse difficulté pour streamer le json à modifier et le json de patch en même temps, sans être obligé de faire un buffer local pour l'un des deux.
2. de la désérialization vers un objet spécifique, mappant des clefs et des actions, au lieu de clefs et valeurs à interpréter. En plus avec des actions, on peut traiter l'application sur un objet du type org.json.JSONObject, ou com.google.gson.JsonObject. On peut toujours streamer le json à modifier...
3. Sinon, il y a toujours la désérialization en "jsonobject" de l'api qu'on veut (org.json, Jackson, GSon...) dont les classes permettent de distinguer la présence ou la valeur "NULL"...
   
   A noter, qu'on peut s'inspirer de ce qui est fait dans org.json pour traiter cette distinction : la valeur "NULL" n'est pas null, mais un singleton de java.lang.Object. Dans une API à la Gson, ce sera une méthode de test (genre isNull()). On est toutefois obligé d'utiliser un Optionnal<Object>. Pour résoudre ça, soit on fait plusieurs valeurs de "NULL", une pour chaque type, ou on utilise un wrapper, comme le JsonElement de GSon.
   Ainsi, on pourra faire
   
   Code:

   ---

   1 2 3 4 5 6 7 8

   Optional<JsonElement> value = json.getValue(fieldname); if ( !value.isPresent() ) { // clef inexistente } else if ( opt.filter(JsonElement::isJsonNull).isPresent() ) { // valeur null }

   ---