> APIs > API Platform 3: Seguridad para tus tesoros
Buy Access to Course
35.

Extensión de consulta: Autofiltrar una colecció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

Cuando obtenemos una colección de tesoros, actualmente devolvemos todos los tesoros, incluso los inéditos. Probablemente algunos de ellos sean inéditos. Añadimos un filtro para controlar esto... pero seamos sinceros, no es la mejor solución. En realidad, necesitamos no devolver tesoros inéditos en absoluto.

Busca la Guía de actualización de la API Platform... y busca la palabra "estado" para encontrar una sección que habla de "proveedores" y "procesadores". Antes hemos hablado de los procesadores de estado, como el PersistProcessorde las operaciones Put y Post, que se encarga de guardar el artículo en la base de datos.

Proveedores de estado

Pero cada operación también tiene algo llamado proveedor de estado. Éste es el responsable de cargar el objeto o colección de objetos. Por ejemplo, cuando hacemos una petición GET para un único elemento, el ItemProvider es el responsable de tomar el ID y consultar la base de datos. También hay un CollectionProviderpara cargar una colección de elementos.

Así que si queremos ocultar automáticamente los tesoros no publicados, una opción sería decorar este CollectionProvider, de forma muy parecida a como hicimos con el PersistProcessor. Excepto... que eso no funcionará del todo. ¿Por qué? El CollectionProvider de Doctrine ejecuta la consulta y devuelve los resultados. Así que lo único que podríamos hacer es coger esos resultados... y luego ocultar los que no queramos. Eso... no es lo ideal para el rendimiento -imagínate cargar 50 tesoros y luego mostrar sólo 10- y confundiría la paginación. Lo que realmente queremos hacer es modificar la propia consulta: añadir unWHERE isPublished = true.

Probar el comportamiento

Por suerte para nosotros, este CollectionProvider "proporciona" su propio punto de extensión que nos permite hacer exactamente eso.

Antes de meternos de lleno, actualicemos una prueba para mostrar el comportamiento que queremos. BuscatestGetCollectionOfTreasures(). Toma el control de estos 5 tesoros y conviértelos todos en isPublished => true:

185 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 12
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 15 - 16
public function testGetCollectionOfTreasures(): void
{
DragonTreasureFactory::createMany(5, [
'isPublished' => true,
]);
// ... lines 22 - 44
}
// ... lines 46 - 183
}

porque ahora mismo, en DragonTreasureFactory, isPublished está configurado con un valor aleatorio:

75 lines | src/Factory/DragonTreasureFactory.php
// ... lines 1 - 29
final class DragonTreasureFactory extends ModelFactory
{
// ... lines 32 - 46
protected function getDefaults(): array
{
return [
// ... lines 50 - 51
'isPublished' => self::faker()->boolean(),
// ... lines 53 - 56
];
}
// ... lines 59 - 73
}

Luego añade uno más con createOne() y isPublished falsos:

185 lines | tests/Functional/DragonTreasureResourceTest.php
// ... lines 1 - 12
class DragonTreasureResourceTest extends ApiTestCase
{
// ... lines 15 - 16
public function testGetCollectionOfTreasures(): void
{
DragonTreasureFactory::createMany(5, [
'isPublished' => true,
]);
DragonTreasureFactory::createOne([
'isPublished' => false,
]);
// ... lines 25 - 44
}
// ... lines 46 - 183
}

¡Impresionante! Y aún queremos afirmar que esto devuelve sólo 5 elementos. Así que... asegurémonos de que falla:

symfony php bin/phpunit --filter=testGetCollectionOfTreasures

Y... ¡sí! Devuelve 6 elementos.

Extensiones de la consulta de colección

Bien, para modificar la consulta de una ruta de colección, vamos a crear algo llamado extensión de consulta. En cualquier lugar de src/ - yo lo haré en el directorio ApiPlatform/- crea una nueva clase llamada DragonTreasureIsPublishedExtension. Haz que implemente QueryCollectionExtensionInterface, luego ve a "Código"->"Generar" oCommand+N en un Mac - y genera el único método que necesitamos: applyToCollection():

17 lines | src/ApiPlatform/DragonTreasureIsPublishedExtension.php
// ... lines 1 - 2
namespace App\ApiPlatform;
use ApiPlatform\Doctrine\Orm\Extension\QueryCollectionExtensionInterface;
use ApiPlatform\Doctrine\Orm\Util\QueryNameGeneratorInterface;
use ApiPlatform\Metadata\Operation;
use Doctrine\ORM\QueryBuilder;
class DragonTreasureIsPublishedExtension implements QueryCollectionExtensionInterface
{
public function applyToCollection(QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator, string $resourceClass, Operation $operation = null, array $context = []): void
{
// TODO: Implement applyToCollection() method.
}
}

Esto está muy bien: nos pasa el $queryBuilder y algunos datos más. Luego, podemos modificar ese QueryBuilder. ¿Lo mejor? El QueryBuilderya tiene en cuenta cosas como la paginación y cualquier filtro que se haya aplicado. Así que no tenemos que preocuparnos de esas cosas.

Además, gracias al sistema de autoconfiguración de Symfony, sólo con crear esta clase y hacer que implemente esta interfaz, ¡ya será llamada cada vez que se utilice una ruta de colección!

Lógica de extensión de consulta

De hecho, se llamará para cualquier recurso. Así que lo primero que necesitamos esif (DragonTreasure::class !== $resourceClass) -afortunadamente nos pasa el nombre de la clase- y luego return:

24 lines | src/ApiPlatform/DragonTreasureIsPublishedExtension.php
// ... lines 1 - 7
use App\Entity\DragonTreasure;
// ... lines 9 - 10
class DragonTreasureIsPublishedExtension implements QueryCollectionExtensionInterface
{
public function applyToCollection(QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator, string $resourceClass, Operation $operation = null, array $context = []): void
{
if (DragonTreasure::class !== $resourceClass) {
return;
}
// ... lines 18 - 21
}
}

A continuación, aquí es donde nos ponemos manos a la obra. Ahora, cada objeto QueryBuilder tiene un alias raíz que hace referencia a la clase o tabla que estás consultando. Normalmente, creamos el QueryBuilder... como desde dentro de un repositorio decimos algo como $this->createQueryBuilder('d') y d se convierte en ese "alias raíz". Luego lo utilizamos en otras partes de la consulta.

Sin embargo, en esta situación, no creamos el QueryBuilder, así que nunca elegimos ese alias raíz. Lo eligieron por nosotros. ¿Qué es? Es "plátano". En realidad, ¡no tengo ni idea de lo que es! Pero podemos conseguirlo con $queryBuilder->getRootAliases()[0]:

24 lines | src/ApiPlatform/DragonTreasureIsPublishedExtension.php
// ... lines 1 - 10
class DragonTreasureIsPublishedExtension implements QueryCollectionExtensionInterface
{
public function applyToCollection(QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator, string $resourceClass, Operation $operation = null, array $context = []): void
{
if (DragonTreasure::class !== $resourceClass) {
return;
}
$rootAlias = $queryBuilder->getRootAliases()[0];
// ... lines 20 - 21
}
}

Ahora es sólo lógica de consulta normal: $queryBuilder->andWhere() pasando sprintf(). Esto parece un poco raro: %s.isPublished = :isPublished, luego pasa $rootAliasseguido de ->setParameter('isPublished', true):

24 lines | src/ApiPlatform/DragonTreasureIsPublishedExtension.php
// ... lines 1 - 10
class DragonTreasureIsPublishedExtension implements QueryCollectionExtensionInterface
{
public function applyToCollection(QueryBuilder $queryBuilder, QueryNameGeneratorInterface $queryNameGenerator, string $resourceClass, Operation $operation = null, array $context = []): void
{
if (DragonTreasure::class !== $resourceClass) {
return;
}
$rootAlias = $queryBuilder->getRootAliases()[0];
$queryBuilder->andWhere(sprintf('%s.isPublished = :isPublished', $rootAlias))
->setParameter('isPublished', true);
}
}

¡Genial! ¡Gira para probar esto!

symfony php bin/console phpunit --filter=testGetCollectionOfTreasures

¡Misión cumplida! Así de fácil.

¿Extensiones de consulta en los Subrecursos?

Por cierto, ¿funcionará también con los subrecursos? Por ejemplo, en nuestros documentos, también podemos obtener una colección de tesoros visitando/api/users/{user_id}/treasures. ¿Esto también ocultará los tesoros no publicados? La respuesta es... ¡sí! Así que no es algo de lo que debas preocuparte. No lo mostraré, pero esto también utiliza la extensión de consulta.

Ah, y si quieres que los usuarios administradores puedan ver los tesoros no publicados, puedes añadir una lógica que sólo modifique esta consulta si el usuario actual no es administrador.

A continuación: ¡esta extensión de consulta arregla la ruta de recogida! Pero... alguien aún podría obtener un único tesoro no publicado directamente por su id. ¡Vamos a arreglarlo!