Operaciones
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
With a Subscription, click any sentence in the script to jump to that part of the video!
Login SubscribePongamos manos a la obra para personalizar nuestra API. Una API RESTful se basa en recursos. Tenemos un recurso -nuestro CheeseListing
- y, por defecto, la Plataforma API ha generado 5 rutas para él. Estos se llaman "operaciones".
Operaciones de colección y de elementos
Las operaciones se dividen en dos categorías. En primer lugar, las operaciones de "colección". Son las URL que no incluyen {id}
y en las que el "recurso" sobre el que operas es técnicamente la "colección de listados de quesos". Por ejemplo, estás "obteniendo" la colección o estás "añadiendo" a la colección con POST.
Y en segundo lugar, las operaciones de "artículos". Estas son las URL que sí tienen la parte {id}
, cuando estás "operando" sobre un único recurso de listado de quesos.
Lo primero que podemos personalizar es qué operaciones queremos realmente Por encima deCheeseListing
, dentro de la anotación, añade collectionOperations={}
con"get"
y "post"
dentro. Luego itemOperations
con {"get", "put", "delete"}
.
Tip
A partir de ApiPlatform 2.5, también hay una operación patch
. Funciona como la operación put
y se recomienda sobre put
cuando sólo quieres cambiar algunos campos (que es la mayoría de las veces). Para permitir la operación patch
, añade esta configuración:`
// config/packages/api_platform.yaml
api_platform:
patch_formats:
json: ['application/merge-patch+json']
// ... lines 1 - 7 | |
/** | |
* @ApiResource( | |
* collectionOperations={"get", "post"}, | |
* itemOperations={"get", "put", "delete"} | |
* ) | |
// ... line 13 | |
*/ | |
class CheeseListing | |
// ... lines 16 - 116 |
Gran parte del dominio de la Plataforma API se reduce a aprender qué opciones puedes pasar dentro de esta anotación. Esta es básicamente la configuración por defecto: queremos las cinco operaciones. Así que no es de extrañar que, cuando actualizamos, no veamos ningún cambio. Pero, ¿qué pasa si no queremos permitir a los usuarios eliminar un listado de quesos? Tal vez, en lugar de eso, en el futuro, añadamos una forma de "archivar" los mismos. Eliminar "delete"
.
// ... lines 1 - 7 | |
/** | |
* @ApiResource( | |
// ... line 10 | |
* itemOperations={"get", "put"} | |
* ) | |
// ... line 13 | |
*/ | |
// ... lines 15 - 116 |
En cuanto hagamos eso... ¡boom! Desaparece de nuestra documentación. Sencillo, ¿verdad? ¡Sí! Pero acaban de ocurrir un montón de cosas geniales. Recuerda que, entre bastidores, la interfaz de usuario de Swagger se construye a partir de un documento de especificaciones de la API abierta, que puedes ver en /api/docs.json
. La razón por la que el punto final "eliminar" desapareció de Swagger es que desapareció de aquí. La Plataforma API mantiene actualizado nuestro documento de "especificaciones". Si miraras el documento de especificaciones JSON-LD, verías lo mismo.
Y, por supuesto, también ha eliminado por completo la ruta -puedes comprobarlo ejecutando:
php bin/console debug:router
Sí, sólo GET
, POST
, GET
y PUT
.
Personalizar la URL del recurso (shortName)
Hmm, ahora que lo veo, no me gusta la parte cheese_listings
de las URLs... La Plataforma API la genera a partir del nombre de la clase. Y realmente, en una API, no deberías obsesionarte con el aspecto de tus URLs, no es importante, especialmente -como verás- cuando tus respuestas a la API incluyen enlaces a otros recursos. Pero... podemos controlar esto.
Vuelve a dar la vuelta y añade otra opción: shortName
ajustada a cheeses
.
// ... lines 1 - 7 | |
/** | |
* @ApiResource( | |
// ... lines 10 - 11 | |
* shortName="cheeses" | |
// ... lines 13 - 14 | |
*/ | |
// ... lines 16 - 117 |
Ahora ejecuta de nuevo debug:router
:
php bin/console debug:router
¡Eh! /api/cheeses
! ¡Mucho mejor! Y ahora vemos lo mismo en nuestros documentos de la API.
Personalizar los detalles de la ruta de la operación
Vale: así podemos controlar qué operaciones queremos en un recurso. Y más adelante aprenderemos a añadir operaciones personalizadas. Pero también podemos controlar bastante sobre las operaciones individuales.
Sabemos que cada operación genera una ruta, y la Plataforma API te da un control total sobre el aspecto de esa ruta. Compruébalo: divide itemOperations
en varias líneas. Entonces, en lugar de decir simplemente "get"
, podemos decir "get"={}
y pasar esta configuración extra.
Prueba a poner "path"=
en, no sé, "/i❤️️cheeses/{id}"
.
// ... lines 1 - 7 | |
/** | |
* @ApiResource( | |
// ... line 10 | |
* itemOperations={ | |
* "get"={"path"="/i❤️cheeses/{id}"}, | |
* "put" | |
* }, | |
// ... line 15 | |
* ) | |
// ... line 17 | |
*/ | |
// ... lines 19 - 120 |
Ve a ver los documentos ¡Ja! ¡Eso funciona! ¿Qué más puedes poner aquí? Para empezar, cualquier cosa que se pueda definir en una ruta, se puede añadir aquí - comomethod
, hosts
, etc.
¿Qué más? Bueno, a lo largo del camino, aprenderemos sobre otras cosas específicas de la plataforma API que puedes poner aquí, como access_control
para la seguridad y formas de controlar el proceso de serialización.
De hecho, ¡vamos a aprender sobre ese proceso ahora mismo! ¿Cómo transforma la Plataforma API nuestro objeto CheeseListing
-con todas estas propiedades privadas- en el JSON que hemos estado viendo? Y cuando creamos un nuevo CheeseListing
, ¿cómo convierte nuestro JSON de entrada en un objeto CheeseListing
?
Entender el proceso de serialización puede ser la pieza más importante para desbloquear la Plataforma API.
Hello,
If you are using Symfony 5 with PHP 8, you can use attributes :
`
#[ApiResource(
)]
`