Custom model binding

[najdias]

Hi,

I need a little support if i can do what i intend to do.
I have 2 resources "Users" and "Associations" connected by many to many relationship.
I have a route api/v1/users/{user}/associations to return the user associations.
If i use the user id in the call is all ok for instance api/v1/users/1/associations but what i want to do is to be able to send also the "me" word in the {user} binding so that i can check the authenticated user associations..
Normally in Laravel i can do in AppServiceProvider boot method this

Route::bind('user', function ($value) {
    if ($value === 'me') {
        return auth()->user();
    }
    return User::where('id', $value)->firstOrFail();
});

But since JSON:API middleware is able to substitute the resource binding for the route without resorting to Laravel's implementation how can i have a custom model binding?

[jesseyvanofferen-4s]

I wonder, does the request in such case still reach the request class? If so you can probably alter the request in there and replace the me with the actual ID of the user. Kind of does what the route model binding would do, but instead on a global level it's more request based.

[najdias]

@jesseyvanofferen-4s can you exemplify? the request reaches the request class yes

[jesseyvanofferen-4s]

Inside the Request class of your schema you could perhaps do something like:

public function validated($key = null, $default = null)
    {
        $validated = parent::validated();
        if (isset($validated['user']) && $validated['user'] === 'me') {
            $validated = array_merge($validated, [
                'user' => [
                 'id' => Auth::user()->id,
                 'type' => UserSchema::type()
            ]
            ]);
        }

        return $validated;
    }

And in your rules it might be best to validate against either a normal identifier OR string me.

[lindyhopchris]

I wouldn't recommend doing this. me isn't a valid resource id in this context, as me is never returned as an id in a users resource.

There's two approaches for doing this:

1. I use separate auth routes, e.g. a route that's /auth/current that returns a JSON:API resource using the data resource response class
2. Use a singular filter so that the /api/v1/users route returns zero or one matching resource, i.e. /api/v1/users?current. Singular filters are documented here.

I've found the first one to be the better approach. I.e. authorization including login, logout and getting the current user are on separate auth endpoints, not part of the JSON:API but still able to return JSON:API resources.

[najdias]

@lindyhopchris thanks for the response. I think i will follow you approach 1 since i couldn't get any way to do it without following that.
thank you all for your help