Chapters

28 Chapters | 2:51:42 |

01

Instalación de la API Platform

7:29
02

Crear tu primer ApiResource

5:44
03

Swagger UI: Documentación interactiva

6:41
04

La potente especificación OpenAPI

5:24
05

JSON-LD: Dar sentido a tus datos

7:21
06

Hydra: Descripción de clases, operaciones y más de la API

4:06
07

Depuración de la API con el Perfilador

5:12
08

Operaciones / Rutas finales

6:38
09

El serializador

9:08
10

Grupos de serialización: Elección de campos

7:28
11

Trucos de serialización

5:15
12

Paginación y accesorios de fundición

5:44
13

Filtros: Buscar resultados

5:14
14

FiltroPropiedades: Conjuntos de campos dispersos

6:55
15

Más formatos: HAL Y CSV

7:10
16

Validación

5:29
17

Crear una entidad de usuario

4:06
18

Recurso API de usuario

5:51
19

Relacionar recursos

7:08
20

Relaciones e IRI

3:40
21

Relaciones incrustadas

5:58
22

Escritura incrustada

7:29
23

Añadir elementos a una propiedad de colección

4:04
24

Crear objetos incrustados

5:34
25

Eliminar elementos de una colección

3:49
26

Filtrar relaciones

3:51
27

Subrecursos

9:54
28

React Admin

9:20

> APIs > Api Platform 3: APIs RESTful míticamente buenas

Buy Access to Course

24.

Crear objetos incrustados

|

|

Autoplay

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.

Start your All-Access Pass

Buy just this tutorial for $12.00

Previous Chapter

Next Challenge

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

Login Subscribe

Login or register to check out the script

14 Comments

Sort By

Login or Register to join the conversation

GM 11 months ago

Help me with
"hydra:description": "The total number of joined relations has exceeded the specified maximum. Raise the limit if necessary with the \"api_platform.eager_loading.max_joins\" configuration key (https://api-platform.com/docs/core/performance/#eager-loading), or limit the maximum serialization depth using the \"enable_max_depth\" option of the Symfony serializer (https://symfony.com/doc/current/components/serializer.html#handling-serialization-depth).",

|

MolloKhan SFCASTS GM 11 months ago edited

Hey @GM

That's an unexpected error. Did you change the default config? Did you download the course code from this page?

Cheers!

|

Fireball 2 years ago edited

Do I get it right that i'ts not possible to update an embedded resource?

I tried to call patch with this:

    {
      "dragonTreasures": [
        { "@id": "/api/treasures/232", "name": "test2", "description": "test" }
      ]
    }

but instead it removed the old one and created the new one completly ignoring @id. As there was no video on updating related entities I get you can only add, assign, delete embedded objects?

|

weaverryan SFCASTS Fireball 1 year ago edited

Hey @Fireball!

Sorry for the slow reply! I think you’re correct and I think it’s by design.

If you think of the dragonTreasures property like any other property, like an array of “favorite sports”, it starts to make sense. You are updating a user by setting a new value for the dragonTreasures property. For simple values like a string, it’s obvious what should happen to the old value: it’s replaced. For array properties, it’s the same (the new value replaces the old value), but it’s less obvious that this should be the case. Actually, I believe that different PATCH content types can be used to control this behavior, though this is theoretical as API Platform, I believe, doesn’t support any wilder PATCH types.

tl;dr Pretty sure you’re right: this is just an explanation into the “why”. Hopefully it’s at least interesting ;).

Cheers!

1 |

Iulian-L 2 years ago

Hi! Great work on the courses!

Regarding the coding challenge for this video, asking us which of the options are not required to make the code work, I would argue that this

C) The Category.products property needs to have Valid constraint on it.

is not necessarily required for the code to work, it's just good practice to have it. Did I understand it wrong?

Thank you!

|

MolloKhan SFCASTS Iulian-L 2 years ago edited

Hey @Iulian-L

That's a very good point. Technically you're correct, if we remove validations, the code will still run and will work but only if you submit valid data. If you submit invalid data it will eventually fail when trying to save it into the database, so in my opinion and from the point of view of the feature, validations are required. What do you think?

Cheers!

|

opalint 2 years ago edited

On the latest version of API Platform (3.2) it looks like Virtual Properties don't seem to work correctly when creating embedded objects. I've added group "user:write" to the "name" and "value" properties in DragonTreasure and they show up in the API Docs correctly and update as expected, however after adding that group to the "setTextDescription" virtual property (with the SerializedName set to "description") it doesn't show up in the docs for the nested object which means a null value error is thrown for the "description" column even if it's added to the payload.

Not sure if it's a bug or configuration issue.

Edit: After further testing it looks like there's just some general weirdness going on with the description property; deleting the virtual property and moving the write groups to it still doesn't allow any User endpoints to update the field. Also adding the "user:read" group to the property doesn't allow the User Get endpoints to see the description. It doesn't make any sense; adding all other fields works exactly as expected so what's so wrong with "description" that it can't be exposed in the nested object?

Edit 2: Turns out that the "description" field is only recognised as writable by if the only group set on the property is "user:write". This makes absolutely no sense and would greatly appreciate any insight into why this would be the case.

|

weaverryan SFCASTS opalint 2 years ago

Hey @opalint!

So using #[Groups(['user:write'])] works, right? But #[Groups(['user:write', 'foo:bar'])] suddenly does not work? That, indeed, does not make sense. As soon as you have even 1 group, adding additional groups should only make the field MORE readable or MORE writable... not less-so (unless I'm completely mis-thinking at the moment). So if this is what you are experiencing, that is not the behavior I would expect either and I can't explain it :/

Cheers!

|

Lukasz-W 2 years ago

Hello,

Is it allowed to update embedded objects in ManyToMany relation?
For now if I do it. There is new object created and swapped to relation. Im not sure if it's correct result, or I'm doing something wrong.

I think same thing happen to me in OneToMany relation. even I add "@id": it's creating new object with new Id and remove old one.

I think there is some different in PUT and PATCH working, seems like PUT works fine for it.

|

weaverryan SFCASTS Lukasz-W 2 years ago

Hey @Lukasz-W!

You're right that ManyToMany should work the same as OneToMany: setting the "many" side of the relationship is really the same for both of these cases.

even I add "@id": it's creating new object with new Id and remove old one.

Hmm, yea, that should not be happening.

I think there is some different in PUT and PATCH working, seems like PUT works fine for it.

It's possible. So, you have no problems with PUT ? Things work as expected? But as soon as you change to PATCH it always creates a new object? That's possible - but it would be surprising. The logic for that is in the normalizer - https://github.com/api-platform/core/blob/main/src/JsonLd/Serializer/ItemNormalizer.php#L143-L151 - which doesn't, generally-speaking, operate differently based on which operation is being used.

So.... I'm not sure what's going on here to be honest - it looks like the wrong behavior...

Cheers!

|

Lukasz-W weaverryan 2 years ago

Oh it's looks like api platform known error
https://github.com/api-platform/core/issues/4293

Adding PatchAwareItemNormalizer seems to fix the problem.

Thanks for answer :)

|

weaverryan SFCASTS Lukasz-W 2 years ago

Ah, good find! So this is a "this is how PATCH is meant to work" situation... which is probably not what you want, but at least we know now!

|

Jeremy 2 years ago

Hi!

How can you prevent from stealing while allowing to edit collections like you did here?
For now, I prevent writing in collections like this (when there is ownership-like stuff) and manage to handle it in opposite side.

Cheers

|

weaverryan SFCASTS Jeremy 2 years ago

Hey @Jeremy!

For now, I prevent writing in collections like this (when there is ownership-like stuff) and manage to handle it in opposite side.

First, good job spotting this potential issue! Honestly, what you said is the safest and simplest way. We CAN prevent stealing, but it adds complexity (both to the code and... just to my brain, lol). We talk about how to prevent stealing in the next tutorial - https://symfonycasts.com/screencast/api-platform-security/unit-of-work-validator

Cheers!

|

Symfony 6.2 API Platform 3.0

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": ">=8.2",
        "ext-ctype": "*",
        "ext-iconv": "*",
        "api-platform/core": "^3.0", // v3.0.8
        "doctrine/annotations": "^1.0", // 1.14.2
        "doctrine/doctrine-bundle": "^2.8", // 2.8.0
        "doctrine/doctrine-migrations-bundle": "^3.2", // 3.2.2
        "doctrine/orm": "^2.14", // 2.14.0
        "nelmio/cors-bundle": "^2.2", // 2.2.0
        "nesbot/carbon": "^2.64", // 2.64.1
        "phpdocumentor/reflection-docblock": "^5.3", // 5.3.0
        "phpstan/phpdoc-parser": "^1.15", // 1.15.3
        "symfony/asset": "6.2.*", // v6.2.0
        "symfony/console": "6.2.*", // v6.2.3
        "symfony/dotenv": "6.2.*", // v6.2.0
        "symfony/expression-language": "6.2.*", // v6.2.2
        "symfony/flex": "^2", // v2.2.4
        "symfony/framework-bundle": "6.2.*", // v6.2.3
        "symfony/property-access": "6.2.*", // v6.2.3
        "symfony/property-info": "6.2.*", // v6.2.3
        "symfony/runtime": "6.2.*", // v6.2.0
        "symfony/security-bundle": "6.2.*", // v6.2.3
        "symfony/serializer": "6.2.*", // v6.2.3
        "symfony/twig-bundle": "6.2.*", // v6.2.3
        "symfony/ux-react": "^2.6", // v2.6.1
        "symfony/validator": "6.2.*", // v6.2.3
        "symfony/webpack-encore-bundle": "^1.16", // v1.16.0
        "symfony/yaml": "6.2.*" // v6.2.2
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.4", // 3.4.2
        "symfony/debug-bundle": "6.2.*", // v6.2.1
        "symfony/maker-bundle": "^1.48", // v1.48.0
        "symfony/monolog-bundle": "^3.0", // v3.8.0
        "symfony/stopwatch": "6.2.*", // v6.2.0
        "symfony/web-profiler-bundle": "6.2.*", // v6.2.4
        "zenstruck/foundry": "^1.26" // v1.26.0
    }
}

Previous Chapter

Next Challenge