> APIs > Api Platform 3: APIs RESTful míticamente buenas
Buy Access to Course
11.

Trucos de serialización

|

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

En cierto modo, hemos engañado al sistema para que permita un campo textDescription cuando enviamos datos. Esto es posible gracias a nuestro método setTextDescription(), que ejecutanl2br() en la descripción que se envía a nuestra API. Esto significa que el usuario envía un campo textDescription cuando edita o crea un tesoro... pero recibe un campo description cuando lo lee.

152 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 34
class DragonTreasure
{
// ... lines 37 - 93
#[Groups(['treasure:write'])]
public function setTextDescription(string $description): self
{
$this->description = nl2br($description);
return $this;
}
// ... lines 101 - 150
}

Y eso está totalmente bien: está permitido tener diferentes campos de entrada frente a campos de salida. Pero sería un poco más guay si, en este caso, ambos se llamaran simplementedescription.

SerializedName: Controlar el nombre del campo

Entonces... ¿podemos controlar el nombre de un campo? Por supuesto que sí Lo hacemos, como ya habrás previsto, mediante otro maravilloso atributo. Éste se llamaSerializedName. Pásale description:

152 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 34
class DragonTreasure
{
// ... lines 37 - 93
#[Groups(['treasure:write'])]
public function setTextDescription(string $description): self
{
$this->description = nl2br($description);
return $this;
}
// ... lines 101 - 150
}

Esto no cambiará cómo se lee el campo, pero si actualizamos los documentos... y miramos la ruta PUT... ¡sí! Ahora podemos enviar un campo llamado description.

Argumentos del constructor

¿Qué pasa con los argumentos del constructor en nuestra entidad? Cuando hacemos una petición a POST, por ejemplo, sabemos que utiliza los métodos setter para escribir los datos en las propiedades.

Ahora prueba esto: busca setName() y elimínalo. Luego ve al constructor y añade allí un argumentostring $name en su lugar. A continuación, di $this->name = $name.

162 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 35
class DragonTreasure
{
// ... lines 38 - 67
public function __construct(string $name)
{
$this->name = $name;
$this->plunderedAt = new \DateTimeImmutable();
}
// ... lines 73 - 160
}

Desde una perspectiva orientada a objetos, el campo puede pasarse cuando se crea el objeto, pero después es de sólo lectura. Diablos, si quisieras ponerte elegante, podrías añadir readonly a la propiedad.

Veamos qué aspecto tiene esto en nuestra documentación. Abre la ruta POST. ¡Parece que aún podemos enviar un campo name! Haz la prueba pulsando "Probar"... y añadamos un Giant slinky que ganamos a un gigante de la vida real en... una partida de póquer bastante tensa. Es bastante valioso, tiene un coolFactor de 8, y dale undescription. Veamos qué ocurre. Pulsa "Ejecutar" y... ¡ha funcionado! Y podemos ver en la respuesta que se ha fijado el name. ¿Cómo es posible?

Bueno, si bajas y miras la ruta PUT, verás que aquí también se anuncia name. Pero... sube a buscar el id del tesoro que acabamos de crear - para mí es el 4, pon el 4 aquí para editarlo... y luego envía sólo el campo nombre para cambiarlo. Y... ¡no cambió! Sí, igual que con nuestro código, una vez creado un DragonTreasure, el nombre no se puede cambiar.

Pero... ¿cómo hizo la petición a POST para establecer el nombre... si no hay ningún establecedor? La respuesta es que el serializador es lo suficientemente inteligente como para establecer los argumentos del constructor... si el nombre del argumento coincide con el nombre de la propiedad. Sí, el hecho de que el argumento se llame namey la propiedad también se llame name es lo que hace que esto funcione.

Observa: cambia el argumento a treasureName en ambos lugares:

162 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 35
class DragonTreasure
{
// ... lines 38 - 67
public function __construct(string $name)
{
$this->name = $name;
$this->plunderedAt = new \DateTimeImmutable();
}
// ... lines 73 - 160
}

Ahora, gira, actualiza y comprueba la ruta POST. El campo ha desaparecido. API Platform ve que tenemos un argumento treasureName que podría enviarse, pero como treasureName no corresponde a ninguna propiedad, ese campo no tiene ningún grupo de serialización. Así que no se utiliza. Lo cambiaré de nuevo a name:

162 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 35
class DragonTreasure
{
// ... lines 38 - 67
public function __construct(string $name)
{
$this->name = $name;
$this->plunderedAt = new \DateTimeImmutable();
}
// ... lines 73 - 160
}

Al utilizar name, mira la propiedad name, y lee sus grupos de serialización.

Args del constructor opcionales frente a obligatorios

Sin embargo, sigue habiendo un problema con los argumentos del constructor que debes tener en cuenta. Actualiza la documentación.

¿Qué pasaría si nuestro usuario no pasara ningún name? Pulsa "Ejecutar" para averiguarlo. De acuerdo Obtenemos un error con un código de estado 400... pero no es un error muy bueno. Dice

No se puede crear una instancia de App\Entity\DragonTreasure a partir de datos serializados porque su constructor requiere que el parámetro name esté presente.

Eso es... en realidad demasiado técnico. Lo que realmente queremos es permitir que la validación se encargue de esto... y hablaremos de la validación en breve. Pero para que la validación funcione, el serializador tiene que poder hacer su trabajo: tiene que poder instanciar el objeto:

162 lines | src/Entity/DragonTreasure.php
// ... lines 1 - 35
class DragonTreasure
{
// ... lines 38 - 67
public function __construct(string $name = null)
{
$this->name = $name;
$this->plunderedAt = new \DateTimeImmutable();
}
// ... lines 73 - 160
}

Vale, inténtalo ahora... ¡mejor! Vale, es peor: un error 500, pero lo arreglaremos con la validación dentro de unos minutos. El caso es que el serializador ha sido capaz de crear nuestro objeto.

A continuación: Para ayudarnos mientras desarrollamos, vamos a añadir un rico conjunto de accesorios de datos. Luego jugaremos con una gran función que API Platform nos ofrece gratuitamente: la paginación