API Platform 3 Part 1: Mythically Good RESTful APIs

Hey @Evgeny

We do not cover QraphQL in these videos but ApiPlatform docs are very good, you may want to give it a read https://api-platform.com/docs/core/graphql/

Cheers!

It's a pity, as always, not everything is clear from the documentation, for example, how can I return DTO instead an entity object. It would be great if you recorded additional videos on graphql.

Thanks for your feedback, I'll pass your message to the team. We love to know what our users want to learn. In the meantime, I can recommend you to watch these videos where we introduce a DTO into an ApiPlatform project, but it's written for version 2, however, the logic is still relevant but the code will change for version 3
https://symfonycasts.com/screencast/api-platform-extending/output-class

Oh, and here are the docs about DTOs https://api-platform.com/docs/core/dto/

Cheers!

Oh, and also, I'm literally coding up episode 3 right now - https://symfonycasts.com/screencast/api-platform3-extending - where we go extensively into DTO's :)

Thanks for the answer! Will annotations with api-platform settings work for a graphql?

I'm not sure about that. As far as I know, ApiPlatform 3 moved from annotations to PHP attributes, which are faster and more reliable.

Haha, quite "averagely", I would agree! Looking at all the old syntax - the annotations, etc - no fun. We're going to get these out as quickly as we can - I've nearly got all of the audio recorded (and all the video is already done).

Cheers!

Hey @Yangzhi!

Sorry for my very slow reply! Ok, on a very low level, the error means that you're missing a "data" request attribute. This is normally set via one of the listeners. I believe, in the case of a POST, that it's set right here - https://github.com/api-platform/core/blob/main/src/Symfony/EventListener/DeserializeListener.php#L102-L106

Assuming I'm correct, the question is: why does that listener exit before setting the request attribute? Based on tour deserialize: false - I'm guessing it's this line - https://github.com/api-platform/core/blob/main/src/Symfony/EventListener/DeserializeListener.php#L84 - but I know why you have deserialize: false. On the docs - https://api-platform.com/docs/core/file-upload/ - they also show setting a custom controller for this (which would not require that data attribute). You might just be missing that part?

Cheers!

Hi @Yangzhi!

Hmm. I'm honestly not sure how to do this - and I would avoid it if possible. It's very not RESTful (the POST endpoint is supposed to be a singular endpoint, but in creating a single item and returning a single item), which is fine (you don't always need to follow the result), but as API Platform tries to be RESTful, doing something like this is quite custom. There MAY be some trick to do it, but I'm not sure. Again, I'd try to avoid this... but you could perhaps create a totally custom operation via a controller to try to do this.

Good luck and sorry I can't be more helpful!

Hey @Yangzhi

You need to catch the exception, probably in your controller, and just return a response as always, you can set the response with the exception error message, and also set the HTTP status code accordingly

Cheers!

Hey @May-S

Thanks for your kind words. About your question, I'm not sure what you mean by "using an offset" but have you read the last topics of the documentation? https://api-platform.com/docs/core/pagination/#controlling-the-behavior-of-the-doctrine-orm-paginator
I believe you'll need to extend or create a custom paginator

Cheers!

Hey @MolloKhan thanks for your reply.
I mean by my question, that I can pass a param named 'offset' or 'started_from' in the query and then this offset which gonna be set in the first result of the query. It's the same aspect searched here https://github.com/api-platform/core/issues/4672.
I've tried to create an extension for the paginator but the class https://github.com/api-platform/core/blob/main/src/Doctrine/Orm/Extension/PaginationExtension.php is final. Have any ideas plz ?

Ohh, it seems like they never implemented that feature. You'll have to decorate the PaginationExtension class then, or create a custom paginator. Here's an example about how to decorate an ApiPlatform service https://api-platform.com/docs/core/state-processors/#creating-a-custom-state-processor

I hope it helps. Cheers!

Hello!
Thanks, but It does not solve the problem.
However I've set a solution, for anybody who need it https://github.com/api-platform/core/issues/4672#issuecomment-1557480806.

Hey @Rokas-P!

Unfortunately, custom data providers will be covered, but not until episode 3. If you're trying to customize how a collection of entities is returned, then you should use a query extension instead. If this is a more custom source, I haven't done this yet, but you can look at how the ORM pagination works. The process is:

A) CollectionProvider is the provider used for the ORM: https://github.com/api-platform/core/blob/main/src/Doctrine/Orm/State/CollectionProvider.php

B) At first, it looks like there is nothing related to pagination, and this returns the final result on the bottom. BUT, just above the bottom, it checks to see if any extensions implement QueryResultCollectionExtensionInterface. And they do, it calls them and returns THAT result instead. This is a sneaky way of calling PaginationExtension: https://github.com/api-platform/core/blob/main/src/Doctrine/Orm/Extension/PaginationExtension.php

C) PaginationExtension::getResult() returns a Paginator object. THAT is the key.

So the long story is that, if you want your custom data provider to allow pagination, instead of returning the array of results, you should return a Paginator. Well, not THAT Paginator, as that's from the ORM. I think you'll need to create a custom class that implements PaginatorInterface (or more likely extends AbstractPaginator).

Let me know if this helps :).

Cheers!

Hey,

Thanks for feedback and course idea!

Cheers!

Hey Martin!

Hmm, maybe! I have one other friend that is doing the upgrade on a pretty big project and has been hitting some issues. Are there any specific things with upgrading that you're interested in? Or just a general request because you'll need to upgrade an app at some point?

Cheers!

Hy Ryan,

sorry for the late answer.

I'm working on a project with multiple Microservices which are based on Symfony 5.4 and Api-platform 2.7. These will have to be upgraded to Symfony6 and Apip3 sooner or later. In my opinion better sooner than later. The heavy lifting was done in the upgrade from 2.6. to 2.7 with the new syntax, but there are some deprecations I just don't seem to get rid off.
And that's the point where your upgrading symfony course really helped me and I would have the hopes, that upgrading apip would do the same :D

for example:

Since api-platform/core 2.7: The $exceptionOnNoToken parameter in "ApiPlatform\Symfony\Security\ResourceAccessChecker::__construct()" is deprecated and will always be false in 3.0, you should stop using it.

Ignore that deprecation in my last comment. I upgraded to Symfony 6.2 and apip 3.1 just to see if it works and this and another deprecation just went away. A bit jarring for me, because I don't have that much Symfony experience, but sometimes you just have to try.

Nice work Martin! That deprecation indeed looks odd. The deprecations system in Symfony is GREAT, but sometimes they're a bit internal and it's not obvious what's needed :)