…what does that mean? Right now, it means nothing has changed: our PUT operation behaves like it always has. But, in API Platform 4, the behavior of PUT will change dramatically. And, at some point between now and then, we need to opt into that…

…be it! We now have a good old-fashioned, boring entity class. In src/ApiPlatform/, let's also delete AdminGroupsContextBuilder. This was a complex way to make fields readable or writable by our admin... but we're going to solve that with ApiProperty security. Also…

…those fields from inside our data mapper. Then API Platform handles transforming them into IRIs. One thing we haven't talked about is being able to write to one of these relation fields. When we use this post() endpoint, we don't need to send…

…user in the database. But... it didn't like it! Why? Because in API Platform and, commonly, in modern API development in general, we do not use ids to refer to resources: we use IRIs. For me, this was strange at first... but I quickly…

…things that we did in the last course was create a custom data persister: UserDataPersister: Let's see why we did this, use decoration to make it more powerful and learn how data persisters are different than some other parts of ApiPlatform, like context builders.

…providers that load one object for the item operations. Normally, we don't need to think about this system because API Platform has a built-in Doctrine data provider that handles all of it for us. But if we want to load some extra data…

…I know, we're getting crazy, but I want to keep seeing how far we can push API Platform's abilities. This new field will be similar to isMe... but just different enough that it will lead us to an alternate solution. Suppose some users…

…In DailyStats, to serialize - or "normalize" - we're using a group called daily-stats:read: Whenever API Platform sees an embedded object: It looks at that object - so CheeseListing - and looks to see if any of its fields are in that same group. And there…

…actually work, we need to write code that converts our CheeseListing object into a CheeseListingOutput object so that API Platform can serialize it. The "thing" that does that is called a data transformer. Let's create one in the src/ directory: add a new directory…

With an input DTO, the update process works like this. First ApiPlatform queries for the CheeseListing entity. Second, the JSON is deserialized into a new CheeseListingInput object. And third, our transform() method is called, where we take that CheeseListingInput object's data and move it…

…down to $isPublished. Paste this above. And now, we don't need the properties option anymore... API Platform figures that out on its own: The result? The same as before. I won't try it, but if you peek at the collection endpoint, it still…

…API how users are able to authenticate. Fortunately we can do this via API Platform. Open up config/packages/api_platform.yaml. And a new key called swagger, though we're actually configuring the OpenAPI docs. To add a new way of authenticating, set api…

…scopes, and then it would create that token and set it into the header This totally does not work right now, but check out Browser's docs to learn how. Next: in API Platform 3.1, the behavior of the PUT operation is changing. Let…

…the endpoint works beautifully. If we try an invalid id, our provider returns null and API Platform takes care of the 404. Side note: if you follow some of these related treasures, they may 404 as well. Let's see... we have 21 and 27…

…by title? These are called "filters": ways to see a "subset" of a collection based on some criteria. And API Platform comes with a bunch of them built-in! Let's start by making it possible to only return published cheese listings. Well, in a…

…s because API Platform shows 30 results per page, by default. Because I don't feel like adding 20 more manually, this is a great time to learn how to change that! First, this can be changed globally in your config/packages/api_platform.yaml…

…go to /api/daily-stats.jsonld, we see all the stats. But if we add ?from=2020-09-01, we want to only show stats on that day or later. Let's do this! Start basically the same way as before: in the src/ApiPlatform/ directory…

…plainPassword field isn't persisted to the database, at the beginning of each request, after API Platform queries the database for the User, plainPassword will always be null. If an API client only sends the username field... because that's all they want to update..…

…create this UserDataPersister class: Now, let's back up real quick. Whenever you use a POST or PUT endpoint, after ApiPlatform deserializes the data into an object and validates it, it tries to save or persist that object. Usually, this means that we're saving…

…We just set the $isMe field on the authenticated User object. One cool thing about Doctrine is that if API platform later queries for that same user, Doctrine will return this exact object in memory, which means that the $isMe field will be set to…