PATCH is trying to create new entity

[FluffyDiscord]

API Platform version(s) affected: x.y.z
3.1.12

Description
I have api resource entity that is only one in the database and it has ID 1. I have set up the entity like this

<?php

namespace App\Entity;

use ApiPlatform\Metadata\ApiResource;
use ApiPlatform\Metadata\Get;
use ApiPlatform\Metadata\Patch;
use App\Repository\SettingsRepository;
use Doctrine\DBAL\Types\Types;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\Serializer\Annotation\Groups;

#[ApiResource(
 operations: [
 new Get(
 uriTemplate: "/settings.{_format}",
 ),
 new Patch(
 uriTemplate: "/settings.{_format}",
 ),
 ],
 normalizationContext: [
 "skip_null_values" => false,
 "groups" => ["settings:read"],
 ],
 denormalizationContext: [
 "skip_null_values" => false,
 "groups" => ["settings:write"],
 ],
)]
#[ORM\Entity(repositoryClass: SettingsRepository::class)]
class Settings
{
 #[ORM\Id]
 #[ORM\GeneratedValue("NONE")]
 #[ORM\Column(type: Types::INTEGER)]
 private int $id = 1;

 #[Groups(["settings:read", "settings:write"])]
 #[ORM\Column(type: Types::TEXT, nullable: true)]
 private ?string $text = null;

 public function getId(): int
 {
 return $this->id;
 }

 public function getText(): ?string
 {
 return $this->text;
 }

 public function setText(?string $text): self
 {
 $this->text = $text;
 return $this;
 }
}

To my surprise I can GET /api/settings the entity just fine. But the PATCH /api/settings throws errors because it's trying to insert new entity and failing because there is already entity with ID 1.

How to reproduce
Use entity from description above, try PATCHing the entity by sending 'text' field

Possible Solution

Additional Context

[mrossard]

your uriTemplates seem wrong - no id specified? Shouldn't it be "/settings/{id}.{_format}" ?

Otherwise you probably should have a specific provider for that, i don't see how api platform is suppposed to work this out by itself.

[FluffyDiscord]

I would like to hide the ID completely. Custom provider that always provide this single entity did not change anything. I would have to make custom processor, but that feels like an overkill to re-implement whole patching mechanism just for single endpoint. Simply passing "id" 1 into "$uriVariables" seems to be ignored

[mrossard]

I would've expected a custom provider to be enough - unless it's detached from the ORM at some point?

I'm pretty sure i've had similar behaviors with standard PUT before, but i don't quite remember exactly what the problem was. I probably just ended up writing a custom processor...

[soyuka]

imo you don't have a previously found data as there is no data read as there are no uri variables, therefore we don't update it ?

[FluffyDiscord]

imo you don't have a previously found data as there is no data read as there are no uri variables, therefore we don't update it ?

as I mentioned in my previous comment, I did try to create custom provider that would always return that one entity no matter what or simply add "id' = 1 to $uriVariables before passing it to the internal provider, yet both were ignored completely, how would I go about making it work without making completely new persist processor ?

[soyuka]

I guess you're not going through:

https://github.com/api-platform/core/blob/main/src/Symfony/EventListener/DeserializeListener.php#L86-L96

also if you're not a safe method (GET) and have no uri variables we don't call your Provider https://github.com/api-platform/core/blob/main/src/Symfony/EventListener/ReadListener.php#L67-L69

I'm in the process of simplifying API Platform extension but you're use case is uncommon so either:

• add uri variables
• use a controller
• use an event listener like our ReadProvider (I'd not do that as we're trying to remove our event listeners for API Platform 4)

[jamesisaac]

I ran into this too the other day -- would like to say the use cases where someone might want to do this probably aren't that uncommon? Mine was:

GET /users/me
PATCH /users/me

In the end I just gave up and put {id} back in the path... but it's not really ideal for the API consumer, would be more convenient if the API looked it up from Symfony Security in a custom Provider.

[soyuka]

use a symfony controller for these? (without using API Platform)

[mrossard]

I ran into this too the other day -- would like to say the use cases where someone might want to do this probably aren't that uncommon? Mine was:

GET /users/me
PATCH /users/me

In the end I just gave up and put {id} back in the path... but it's not really ideal for the API consumer, would be more convenient if the API looked it up from Symfony Security in a custom Provider.

This is doable with a simple custom provider isn't it. You'd just likely have to use a string identifier in your ApiResource, then your provider returns the curretly connected user for "me", otherwise calls the standard provider...If you're reluctant to use a fictitious string identifier, I have once before used "-1" as a magic number for "me" and it worked just fine.

[jamesisaac]

use a symfony controller for these? (without using API Platform)

The features API Platform provides are great though. If we've managed to create all our other API operations with built-in APIP tooling, it's quite a shame to then have to bypass it for an operation like this, when it feels like it should be achievable by a 1-line custom Provider.

Even if the controller can be made quite simple, it's just more to reason about / room for bugs, in terms of the difference between this operation and the others -- which stages of APIP are no longer applied and need to be recreated within the controller.

When the operations contain identifiers which align with the database fields, APIP's custom Provider/Processor patterns works perfectly. Good out-of-the-box defaults but still flexibility to customise when needed. But straying outside this and it does feel like fighting with the operation configuration to get something working. It would be great if there was a documented way to still use custom Providers & Processors with any arbitrary URL. While each individual use-case might be uncommon, the "long tail" of people who have unconventional routes in their API but still want to use APIP for that operation is probably quite large.

This is doable with a simple custom provider isn't it. You'd just likely have to use a string identifier in your ApiResource, then your provider returns the curretly connected user for "me", otherwise calls the standard provider...If you're reluctant to use a fictitious string identifier, I have once before used "-1" as a magic number for "me" and it worked just fine.

Are you sure this worked for you on a PATCH/PUT operation? The GET /users/me operation worked fine with a custom Provider. It was in the Processor in PATCH /users/me which kept trying to persist a new entity. I think I tried something along the lines of making me into the value of an identifier but couldn't get it working.

To clarify the use-case, these /users/me operations are importantly different from the /users/{id} ones -- e.g. they include more fields in the serializer groups which users would only be able to see about themselves. So I was trying to declare them as separate operations from the standard /users/{id} ones.

[FluffyDiscord]

Yes, you said it nicely - it does feel like I am fighting the API Platform whenever I need even just a bit of customization in it. It is very strict

[mrossard]

Are you sure this worked for you on a PATCH/PUT operation? The GET /users/me operation worked fine with a custom Provider. It was in the Processor in PATCH /users/me which kept trying to persist a new entity. I think I tried something along the lines of making me into the value of an identifier but couldn't get it working.

Probably not, i mostly use external authentication. To have PATCH/PUT work you probably need a custom processor too as of right now, i've had similar problems with the standard one trying to persist a new entity. I once tried working on a PR for that but i couldn't get to a satisfying result.

To clarify the use-case, these /users/me operations are importantly different from the /users/{id} ones -- e.g. they include more fields in the serializer groups which users would only be able to see about themselves. So I was trying to declare them as separate operations from the standard /users/{id} ones.

Adding custom operations with their own provider/processor is always doable in my experience. Trying to have them reuse the standard ones can be a challenge though, and sometimes it's just not worth the trouble. The standrad ones are meant for...well, standard uses, and if your needs deviate too much they're probably not the right solution. That's ok IMO, it's just something you have to keep in mind when deciding on how to implement some specific operations.

[mrossard]

Yes, you said it nicely - it does feel like I am fighting the API Platform whenever I need even just a bit of customization in it. It is very strict

Depending on how you're trying to use it, you might consider systematically adding custom providers and processors (that is pretty much mandatory when you separate the Api Resources from the Entities anyway).

That's how i do it, and it somewhat changes how you consider things : instead of being "annoyed" at having to implement replacements for the standard ones when needed, you get to be "pleased" that some of your uses match the standard case and you actually don't have to do it yourself! ;)

[jamesisaac]

I don't think it's even just a case of adding a custom Processor..? My understanding from the snippets @soyuka linked is that there are 2 problems with custom URIs that don't contain identifiers: (1) the custom Provider isn't called, (2) it creates a new entity instead of deserializing into the existing one. So at that point there's so much you'd need to work around in the Processor you might as well just skip APIP completely and do the custom controller.

[mrossard]

I don't think it's even just a case of adding a custom Processor..? My understanding from the snippets @soyuka linked is that there are 2 problems with custom URIs that don't contain identifiers: (1) the custom Provider isn't called, (2) it creates a new entity instead of deserializing into the existing one. So at that point there's so much you'd need to work around in the Processor you might as well just skip APIP completely and do the custom controller.

well I thought the provider was called anyway, but otherwise you're pretty much back to my earlier comment : you can always have an operation for "/users/{stringid}", then you processor does the job of determining whether the id is "me" or numerical.

Then you do have an uriVariable, which triggers the provider call if i understand what @soyuka was saying. From there that's pretty straightforward IMO.