Comment faire correctement le PATCH dans les langues fortement dactylographiées basées sur le ressort-exemple

j'ai eu le même problème, donc voici mes expériences / solutions.

je suggère que vous implémentiez le patch comme il se doit, donc si

• une clé est présente avec une valeur > la valeur est définie
• une clé est présente avec une chaîne vide > la chaîne vide est définie
• une clé est présente, avec une valeur null > le champ est défini sur null
• une clé est absente > la valeur pour cette clé n'est pas changé

si vous ne le faites pas, vous obtiendrez bientôt une api qui est difficile à comprendre.

pour que je laisse tomber votre première option

est D'accord avec le client que s'il veut supprimer une propriété, il doit m'envoyer une chaîne vide (mais qu'en est-il des dates et d'autres types sans chaîne?)

La deuxième option est en fait une bonne option à mon avis. Et c'est également ce que nous avons fait (genre de).

Je ne suis pas sûr que vous puissiez faire fonctionner les propriétés de validation avec cette option, mais encore une fois, cette validation ne devrait-elle pas être sur votre couche domaine? Cela pourrait jeter une exception du domaine qui est géré par la couche rest et traduit en une mauvaise requête.

C'est ainsi que nous l'avons fait dans une application:

class PatchUserRequest {
  private boolean containsName = false;
  private String name;

  private boolean containsEmail = false;
  private String email;

  @Length(max = 100) // haven't tested this, but annotation is allowed on method, thus should work
  void setName(String name) {
    this.containsName = true;
    this.name = name;
  }

  boolean containsName() {
    return containsName;
  }

  String getName() {
    return name;
  }
}
...

le désérialiseur json instanciera la PatchUserRequest mais il appellera seulement la méthode setter pour les champs qui sont présents. Donc le booléen contains pour les champs manquants restera faux.

Dans une autre application, nous avons utilisé le même principe, mais un peu différent. (Je préfère celui-ci)

class PatchUserRequest {
  private static final String NAME_KEY = "name";

  private Map<String, ?> fields = new HashMap<>();;

  @Length(max = 100) // haven't tested this, but annotation is allowed on method, thus should work
  void setName(String name) {
    fields.put(NAME_KEY, name);
  }

  boolean containsName() {
    return fields.containsKey(NAME_KEY);
  }

  String getName() {
    return (String) fields.get(NAME_KEY);
  }
}
...

vous pouvez également faire la même chose en laissant votre PatchUserRequest étendre la carte.

une autre option pourrait être d'écrire votre propre désérialiseur json, mais je n'ai pas essayé cela moi-même.

on pourrait dire que PATCH ne devrait pas être utilisé dans un tel exemple et je devrais utiliser PUT pour mettre à jour mon utilisateur.

Je ne suis pas d'accord. J'utilise aussi PATCH & PUT de la même façon que vous avez déclaré:

• MISE à jour de l'objet avec l'ensemble de sa représentation (remplacer)
• PATCH de mise à jour de l'objet donné, avec uniquement des champs (mise à jour)

comme vous l'avez noté, le problème principal est que nous n'avons pas de valeurs nulles multiples pour distinguer les nulls explicites et implicites. Puisque vous avez étiqueté cette question Kotlin j'ai essayé de trouver une solution qui utilise propriétés déléguées et références de propriété . Une contrainte importante est qu'il fonctionne de manière transparente avec Jackson qui est utilisé par Spring Boot.

l'idée est de stocker information indiquant les champs qui ont été explicitement définis à null en utilisant des propriétés déléguées.

définir D'abord le délégué:

class ExpNull<R, T>(private val explicitNulls: MutableSet<KProperty<*>>) {
    private var v: T? = null
    operator fun getValue(thisRef: R, property: KProperty<*>) = v
    operator fun setValue(thisRef: R, property: KProperty<*>, value: T) {
        if (value == null) explicitNulls += property
        else explicitNulls -= property
        v = value
    }
}

cela agit comme un proxy pour la propriété mais stocke les propriétés nulles dans le donné MutableSet .

maintenant dans votre DTO :

class User {
    val explicitNulls = mutableSetOf<KProperty<*>>() 
    var name: String? by ExpNull(explicitNulls)
}

"151980920 d'Utilisation" est quelque chose comme ceci:

@Test fun `test with missing field`() {
    val json = "{}"

    val user = ObjectMapper().readValue(json, User::class.java)
    assertTrue(user.name == null)
    assertTrue(user.explicitNulls.isEmpty())
}

@Test fun `test with explicit null`() {
    val json = "{\"name\": null}"

    val user = ObjectMapper().readValue(json, User::class.java)
    assertTrue(user.name == null)
    assertEquals(user.explicitNulls, setOf(User::name))
}

cela fonctionne parce que Jackson explicitement appelle user.setName(null) dans le deuxième cas et omet l'appel dans le premier cas.

vous pouvez bien sûr obtenir un peu plus de fantaisie et ajouter quelques méthodes à une interface que votre DTO devrait mettre en œuvre.

interface ExpNullable {
    val explicitNulls: Set<KProperty<*>>

    fun isExplicitNull(property: KProperty<*>) = property in explicitNulls
}

ce qui rend les contrôles un peu plus agréables avec user.isExplicitNull(User::name) .

ce que je fais dans certaines applications est de créer une classe OptionalInput qui peut distinguer si une valeur est définie ou non:

class OptionalInput<T> {

    private boolean _isSet = false

    @Valid
    private T value

    void set(T value) {
        this._isSet = true
        this.value = value
    }

    T get() {
        return this.value
    }

    boolean isSet() {
        return this._isSet
    }
}

puis dans votre classe de demande:

class PatchUserRequest {

    @OptionalInputLength(max = 100L)
    final OptionalInput<String> name = new OptionalInput<>()

    void setName(String name) {
        this.name.set(name)
    }
}

les propriétés peuvent être validées en créant un @OptionalInputLength .

Usage:

void update(@Valid @RequestBody PatchUserRequest request) {
    if (request.name.isSet()) {
        // Do the stuff
    }
}

NOTE: le code est écrit dans groovy mais vous obtenez l'idée. J'ai utilisé cette approche pour quelques API déjà et il semble faire son travail assez bien.