Core: Identifing a resource

Created on 12 Jul 2016  Â·  15Comments  Â·  Source: api-platform/core

Hello,

I'm wondering how to add a user to a resource without knowing the user ID but using the username. For example: "user": "/users?username=polc" instead of "user": "/users/1" with an error "user doesn't exist" if the user doesn't exist.

question

Most helpful comment

I'm using a data provider for those items that have to be fetched by using something different then the ID. You could also fetch the resource with both id and username with the logic in the data provider.

All 15 comments

Hello polc,

You can do this by adding an event listener on the user entity :
Then you will have to get the request, use the repository and find the users or throw if not found.

If you want more insight into this, I can send you an exemple.

@polc You should not do that, even if you could. It's against the principle of JSON-LD.

You should instead send another request to get the user: GET /users?username=polc

@teohhanhui even if he want to assign directly that user ?

Is doing this on embedded relation is also against JSON-LD ?

"user": "/users?username=polc" is just wrong. You're supposed to use the @id (IRI).

It's the same reason why we don't support using the bare integer id either...

"user": "/users/polc" would be correct if /users/polc is the @id. In other words, using the username as id.

"user": "/users/polc" is way better but I don't want to use the username as @id because the user can change his username. I also don't want to do another request to get the user, because mobile client sometimes have limited connection.

Like @Simperfit right now I'm using a listener to populate the user property but I fell bad doing this.

One solution may be to add a secondary IRI based on username. Is this OK from a JSON-LD perspective?

I'm using a data provider for those items that have to be fetched by using something different then the ID. You could also fetch the resource with both id and username with the logic in the data provider.

@soyuka this is a great idea !

Of course you could do such things, but should you? :smile:

Are you trying to have a RESTful API, or trying to work around things? :stuck_out_tongue:

Sometimes yes but if you can avoid it you should indeed.
Le mar. 12 juil. 2016 à 13:21, Teoh Han Hui [email protected] a
écrit :

Of course you could do such things, but should you? 😄

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/api-platform/core/issues/612#issuecomment-232012882,
or mute the thread
https://github.com/notifications/unsubscribe/ABQr81mmE8h1941-QRGuICyVxdIa5Re7ks5qU3iqgaJpZM4JKEYV
.

Can we close this issue?

I think so

@soyuka answer works great but @teohhanhui seem to dislike this solution. Maybe someone have a better idea for this use case ? (everyone have is own solution so it seem it's a very recurrent use case).

@polc, as @teohhanhui it is not really RESTful and defeat the purpose of IRI. But if it suits your specific use case, you're free to use this solution, it is simply just not something we would recommend :)

Was this page helpful?
0 / 5 - 0 ratings