Core: [Question] Identifier and primary key

[polc]

Hello everyone,

I would like for my User resource to have an identifier different from the primary key, for example the email as identifier, but and ID as primary key because the email can change).

Is it currently possible ? (didn't found in the doc).

[soyuka]

https://github.com/api-platform/core/issues/612#issuecomment-231981388

take a look at this one. Basically you'd have to build a data provider, or a custom controller.

[polc]

@soyuka You're right I could create a data provider but I'm looking for an internal way to do this.

For the moment ApiPlatform assume that the REST identifier is a Doctrine primary key.

What I would like to see is if I set user email with @ApiProperty(identifier=true) then instead of using Doctrine primary key, it use the email (for Rest identifier only, entities are still jointed with primary key).

I'm sorry if i'm not clear :s

[soyuka]

If you do this you'll end up with more than one identifier, because Doctrine also sets up metadata for properties (according to your annotations). It's not possible internally.

[polc]

This is very limitative, it mean I can't have a mutable REST identifier like a user name or a group name because they will be used as primary key by Doctrine.

Maybe It's not so hard to separate REST identifier and Doctrine identifiers, I could try to work on it if it's something that could be integrated in Api Platform.

[soyuka]

ping @api-platform/core-team wdyt?

IMO, REST identifiers should be the same as the Resources identifiers which are Datastore identifiers (often unique). REST identifiers should therefore not being mutated/mutable, it just feels weird.

Still, if you really need this, a DataProvider is the easiest thing to add (and it's one of the internal ways of doing this). This is a really specific use case and most of the other entities will be using the same identifier as the Datastore index.

Keep also in mind that Doctrine is not the only one meant to work with ApiPlatform so they're not really linked and you can do REST endpoints without it.

What do you mean by "REST identifiers" btw? The id in the url, or the @id reference in jsonld? Maybe both?

[theofidry]

I second your though on this @soyuka. Not that I can't see your use case of @polc, but IMO this is something that should be done on the developer end not in the core. Should a thing need to be done, it would rather be an entry in the doc would be more appropriate (IMO).

[dunglas]

I agree with @soyuka. Btw, I strongly discourage you to use identifiers that can change for your resources. Consider API identifiers just as PK. It's even more important for hypermedia APIs, see for instance this classic: https://www.w3.org/Provider/Style/URI.html

[soyuka]

@theofidry an entry about data providers? Or about this specific use case we all don't recommend? 😄

Nice link @dunglas thanks.

[theofidry]

@soyuka I think this depends more of the use case than anything. As the API may as well be private, it depends more on your needs than a public API where you have to guarantee some level of commitment and in which, breaking a link is bad.

Also I said "Should a thing need to be done", if we all don't recommend it, then I wouldn't say we need to do something about it ;) But thanks for pointing there's already an entry for data providers I didn't check that :P

[polc]

Okay if we consider API identifiers as PK it make sense, I will follow @dunglas link recommendations (even if it break my heart to have to do 1 request for searching the user, wait for the response and then do the actual request).

I will wait for HTTP 2 and multiple requests which might solve this problem.

[soyuka]

If it's only for the user you can call /api/users/soyuka and do a findOneByUsername in an item data provider no?

[polc]

Yeah but I'm trying to have a very strict API with the least hacks possible :)

[teohhanhui]

@polc I think you're talking about using a surrogate key, right? So the username is indeed unique in the database, but you use another integer ID as the surrogate key.

But the username also needs to be durable (immutable) for it to be suitable for use in the IRI.

[polc]

@teohhanhui yes exactly ! But now I know that IRI must be durable so I abandoned the idea to have the username in the IRI. On a side note It could be a nice improvement to being able to chose the surrogate key!