UUID as a API Identifier

Hey @Ben01

It seems you have your API resource set up correctly, I cannot spot the error. Does it only fail on PUT requests?
How are you making the request?

Cheers!

Hi, Thanks for your reply!
It turns out it was a problem with the version of API Platform. I updated Symfony from 6.3 to 6.4, but didn't update api-platform.
I updated to the latest API-platform version, and now it works again!

Great news!

Hey Marko!

Weird! The error comes from this class - https://github.com/api-platform/core/blob/main/src/Symfony/Routing/IriConverter.php - unfortunately that exact error wording is used 3 times in that file, so it's not clear exactly which "bad path" you're hitting. But it's likely you're hitting one of these 2 errors - https://github.com/api-platform/core/blob/9b4b58ca0113a2645b58a116fe9e4bf200df8aa3/src/Symfony/Routing/IriConverter.php#L171-L191

In both cases, there is a DIFFERENT error that occurs, and then it throws the error you're seeing. However, Symfony DOES display the original error as well. If you open the profiler for this failed request and go to the "Exception" tab, you should see something near the top that says something like "Exceptions 1/2". If you scroll down, eventually you'll see the OTHER exception. It may give you a better clue about what is going wrong. For example, if you left username blank, the system would blow up because it would call ->getUsername() during this process, but the username property would be uninitialized. That's just one possible problem :)

Cheers!

Hi @weaverryan. Thanks a lot for your answer. I managed to fixed this bug with the following code:

    operations: [
        new Delete(uriTemplate: 'users/{username}'),
        new Get(uriTemplate: 'users/{username}'),
        new Put(uriTemplate: 'users/{username}'),
        new Patch(uriTemplate: 'users/{username}'),
        new GetCollection(uriTemplate: 'users'),
        new Post(uriTemplate: 'users')
    ]

Niiice! Thanks for sharing that :)

Oh, I guess the attributions are useful, in case I'm doing something obviously foolish with those. When I "get" /companies/1 I have an IRI for "address", but values for "insertedBy" and "another".

Entity/Users.php

#[ORM\Entity(repositoryClass: UsersRepository::class)]
#[ApiResource(
	normalizationContext: ["groups" => ["users:read", "companies:read"]],
)]
class Users
{
	#[ORM\Id]
	#[ORM\Column(type: 'uuid_binary')]
	#[ApiProperty(identifier: true)]
	#[Groups(['users:read','companies:read'])]
	private $userUuid;

	#[ORM\Id]
	#[ORM\Column(type: 'integer')]
	#[ApiProperty(identifier: false)]
	#[Groups(['users:read'])]
	private $anotherId;

	#[ORM\Column(type: 'string', length: 128, nullable: true)]
	#[Groups(['users:read'])]
	private $jobTitle;

	#[ORM\Column(type: 'integer')]
	#[Groups(['users:read'])]
	private $userPermissionLevel;

Entity/Companies.php

#[ORM\Entity(repositoryClass: CompaniesRepository::class)]
#[ApiResource(normalizationContext: ['groups' => ['companies:read']])]

class Companies
{
	#[ORM\Id]
	#[ORM\GeneratedValue]
	#[ORM\Column(type: 'integer')]
	#[Groups(['companies:read'])]
	private $id;

	#[ORM\ManyToOne(targetEntity: Users::class)]
	#[ORM\JoinColumn(nullable: false, referencedColumnName: "user_uuid", name: "inserted_by")]
	#[ORM\Column(type: 'uuid_binary')]
	#[Groups(['companies:read'])]
	private $insertedBy;

	#[ORM\ManyToOne(targetEntity: Users::class)]
	#[ORM\JoinColumn(nullable: false, referencedColumnName: "another_id", name: "another_id")]
	#[ORM\Column(type: 'integer', name: 'another_id')]
	#[Groups(['companies:read'])]
	private $another;

	#[ORM\OneToOne(targetEntity: Addresses::class)]
	#[Groups(['companies:read'])]
	private $address;

	#[ORM\Column(type: 'datetime_immutable', options: ["default" => "CURRENT_TIMESTAMP"])]
	#[Groups(['companies:read'])]
	private $insertedAt;

Entity/Addresses.php

#[ORM\Entity(repositoryClass: AddressesRepository::class)]
#[ApiResource]
class Addresses
{
	#[ORM\Id]
	#[ORM\GeneratedValue]
	#[ORM\Column(type: 'integer')]
	private $id;

	#[ORM\Column(type: 'string', length: 255)]
	private $companyAddress;

Debugging into the code, I've got a bit further, I think. If I do this, I think it mostly solves question 1 - I get valid IRIs with two parameters for "users". I can curl for the entries in jsonld format, but a web browser gives me the full HMTL interface when I use the /users/uuid/{userUuid}/another/{anotherId} end point with a .jsonld or .json extension.

EDIT: If I remove the 'path' => ... line, the default endpoint, /users/{userUuid}/{anotherId}.jsonld DOES work correctly in a web browser. Weird.

Entity/Users.php

#[ORM\Entity(repositoryClass: UsersRepository::class)]
#[ApiResource(
	itemOperations: [
    'put','patch','delete',
    'get' => [
      'path' => '/users/uuid/{userUuid}/another/{anotherId}',
      'openapi_context' => [
        'parameters' => [
          ['name' => 'userUuid', 'in' => 'path', 'required' => true, 'schema' => ['type' => 'string']],
          ['name' => 'anotherId', 'in' => 'path', 'required' => true, 'schema' => ['type' => 'integer']]
        ]
      ],
    ]
  ],
  normalizationContext: ["groups" => ["users:read", "companies:read"]],
  compositeIdentifier: false
)]
class Users
{
	#[ORM\Id]
	#[ORM\Column(type: 'uuid_binary')]
	#[Groups(['users:read','companies:read'])]
	private $userUuid;

	#[ORM\Id]
	#[ORM\Column(type: 'integer')]
	#[Groups(['users:read'])]
	private $anotherId;

	#[ORM\Column(type: 'string', length: 128, nullable: true)]
	#[Groups(['users:read'])]
	private $jobTitle;

	#[ORM\Column(type: 'integer')]
	#[Groups(['users:read'])]
	private $userPermissionLevel;

Hey Paul-L!

WOOOH. Ok, so you're doing some seriously complex stuff - and it looks like you've made some good headway since your original question (the team was waiting for me to read and reply to your comment).

In general, back to (1), I've actually never created a URL like this - I typically tell people that life is much easier if you let the URL be a filter - e.g. /users/{userUuuid}?another={anotherId}. However, if you've got it working - nice job!

After all of your progress, are you still struggling with any part of this?

Cheers!

Thanks weaverryan.

I think I understand 1) sufficiently now - at least enough to make it work for me - though fighting with this has also helped me find a way to refactor out the composite key in this case anyway.

And I'm pretty sure that the answers to 2) and 3) are that there isn't really a meaningful way to replace two lines on the results from GET /companies/1 (userUuid and anotherId) with a single IRI or a record from the user table - where would it live in the hierarchy?

I suspect the problem I encountered with paths using slugs might be an API platform bug (or user misuse). It doesn't work as I expect with non-composite keys either. If I add 'path'=>'/companies/id/{id}' to the itemOperations "get" entry on Companies, http://127.0.0.1:8000/companies/id/1.jsonld in my web browser takes me to the API Platform OpenAPI web interface but this curl command returns the ld+json entry I'd expect:

curl -X 'GET' 'http://127.0.0.1:8000/companies/id/1' -H 'accept: application/ld+json'

Hey Paul-L!

Sorry for the slow reply - just back from some vacation :).

If I add 'path'=>'/companies/id/{id}' to the itemOperations "get" entry on Companies, http://127.0.0.1:8000/companies/id/1.jsonld in my web browser takes me to the API Platform OpenAPI web interface but this curl command returns the ld+json entry I'd expect:

The ability to add the .jsonld extension and see that in your browser is kind of a "bonus" feature just to make life easier when debugging (because using a browser is nice). This is "powered" by the fact that the routes built by API Platform look like this: /api/cheeses/{id}.{_format}. In your case, for your custom "path", I bet if you added .{_format} to the end, you would get the result you expect. So, it's not a misuse on your part - though you do need a little bit more if you want that nice browser behavior.

Cheers!

Hey Fox C.

Good work on StackOverflow! And thanks for mentioning us!

Cheers!