Cómo hacer el PARCHE correctamente en lenguajes fuertemente tipeados basados en Spring-ejemplo

He tenido el mismo problema, así que aquí están mis experiencias / soluciones.

Le sugeriría que implemente el parche como debe ser, por lo que si

• una clave está presente con un valor > el valor se establece
• una clave está presente con una cadena vacía > la cadena vacía se establece
• una clave está presente con un valor null > el campo se establece en null
• una clave está ausente > el valor de esa clave no se cambia

Si no haces eso, pronto obtendrás una api lo cual es difícil de entender.

Así que me gustaría dejar su primera opción

Está de acuerdo con el cliente en que si quiere eliminar una propiedad debe enviarme una cadena vacía (pero ¿qué pasa con las fechas y otros tipos que no son cadenas?)

La segunda opción es en realidad una buena opción en mi opinión. Y eso es también lo que hicimos (tipo de).

No estoy seguro de si puede hacer que las propiedades de validación funcionen con esta opción, pero de nuevo, si esta validación no está activada la capa de dominio? Esto podría lanzar una excepción del dominio que es manejada por la capa rest y traducida en una solicitud incorrecta.

Así es como lo hicimos en una aplicación:

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;
  }
}
...

El deserializador json instanciará el PatchUserRequest pero solo llamará al método setter para los campos que estén presentes. Por lo tanto, el contenido booleano para los campos faltantes seguirá siendo falso.

En otra aplicación utilizamos el mismo principio, pero un poco diferente. (Prefiero esto uno)

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);
  }
}
...

Usted también podría hacer lo mismo dejando que su PatchUserRequest extienda el mapa.

Otra opción podría ser escribir su propio deserializador json, pero yo no lo he intentado.

Se podría decir que el PARCHE no debería usarse en tal ejemplo y yo debería usar PUT para actualizar a mi Usuario.

No estoy de acuerdo con esto. También uso PATCH & PUT de la misma manera que usted dijo:

• Objeto PUT-update con toda su representación (reemplazar)
• PATCH-update object with given fields only (update)

Como ha señalado, el principal problema es que no tenemos múltiples valores similares a null para distinguir entre null explícitos e implícitos. Desde que etiquetaste esta pregunta Kotlin he intentado encontrar una solución que use Propiedades Delegadas y Referencias de Propiedades. Una restricción importante es que funciona de forma transparente con Jackson, que es utilizado por Spring Boot.

La idea es almacenar automáticamente la información cuyos campos se han establecido explícitamente en null mediante el uso de propiedades delegadas.

Primero defina el delegado:

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
    }
}

Esto actúa como un proxy para la propiedad pero almacena las propiedades null en el MutableSet dado.

Ahora en tu DTO:

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

El uso es algo como esto:

@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))
}

Esto funciona porque Jackson llama explícitamente a user.setName(null) en el segundo caso y omite la llamada en el primer caso.

Por supuesto, puede obtener un poco más de fantasía y agregar algunos métodos a una interfaz que su DTO debe implementar.

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

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

Lo que hace que las comprobaciones sean un poco más agradables con user.isExplicitNull(User::name).

Lo que hago en algunas de las aplicaciones es crear una clase OptionalInput que pueda distinguir si un valor está establecido o no:

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
    }
}

Luego en su clase de solicitud:

class PatchUserRequest {

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

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

Las propiedades se pueden validar creando un @OptionalInputLength.

El uso es:

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

NOTA: El código está escrito en groovy pero se entiende la idea. He utilizado este enfoque para algunas API ya y parece estar haciendo su trabajo bastante bien.