Return encoded route key in JSON output when using OptimusEncodedRouteKey

[ivanvermeyen]

Hello

I'm working on a fairly simple but should-be-flexible posts package to use in different scenarios. I'm using your package and the OptimusEncodedRouteKey trait and found that I needed to change the model's JSON output that gets returned from my API-like routes every time. It doesn't make sense to encode the route key and then expose the real ID, of course.

First I created a new API Resource for each model. This was ok, but added too much extra code for my taste, just to hide the real ID.

Then I tried overriding the toArray() method. This also worked, but if I would put this in a trait, it wouldn't be easy to change toArray(). I would have to duplicate the code.

So I ended up overriding this method instead (jsonSerialize() calls toArray() in the base class):

public function jsonSerialize()
{
    return array_merge(parent::jsonSerialize(), [
        $this->getRouteKeyName() => $this->getRouteKey(),
    ]);
}

Now the ID that gets returned from routes is automatically encoded, I can still override toArray() to alter the rest of the attributes per model. I can also override jsonSerialize() if I want to change how the ID gets returned, but I can't think of a reason to do this...

My fear was that this would cause problems when used with the queue, but that does not seem to be the case. Everything still worked.

Do you think this is something that can be added to the OptimusEncodedRouteKey trait?

[antonkomarev]

Interesting suggestion, Ivan. I'm trying to find any downsides of this approach. The only one I can imagine at this moment if returned route key isn't located in response root.

How does it will work if this structure should be returned?

{
    "data": {
        "id": "encoded-id",
        "title": "This is my title"
    }
}

Do you just returning your model by this way?

public function show(Article $article)
{
    return $article;
}

In my point of view having Response classes for each endpoint adds complexity but gives you much more benefits.

[antonkomarev]

The main reason to have Response classes is the requirement that your API resources shouldn't be tightly coupled with your backend models nor database structure.

Otherwise if you will change structure of your models or refactor database structure - you will break backward compatibility. Your API clients wouldn't be happy at all. Surely extra response layer could be added later when you'll decide to make changes in your codebase, but I like to have it from the start, it isn't too complicated.

Another one reason is content negotiation, when you need to change format or structure of the response accordingly client needs. For example one endpoint will be able to return RSS feed as well.

[ivanvermeyen]

Hello,

I agree that using an API Resource is the optimal way to separate concerns and allow for the most flexible refactoring afterwards. However, in simple, private projects it may be overkill and complicate the code needlessly...

Adding automatic encoding should of course not stand in the way of "upgrading" to a Resource. I'm not entirely sure yet if this is the case with my example...

Perhaps it's also perfectly valid to leave this feature in the hands of the developer...

Also, I've found another issue I need to solve in my project: I need to return encoded foreign keys.

$response->assertJsonFragment([
    'id' => $post->getRouteKey(),
    'collection_id' => $post->collection->getRouteKey(),
]);

I will keep on experimenting with this and report back if I find anything useful. 👍

[deantheiceman]

Is there any new alternative way of doing this with model attributes or something?

[antonkomarev]

@deantheiceman could you explain more what are you trying to achieve?

[deantheiceman]

I was hoping I could overwrite it automatically for all API resources, but I guess writing APIResources is the best way to do it like above mentioned.

is there any plans to support validation like exists:products,id with encoded IDs?

[antonkomarev]

The best way to get new features - create pull request :) Right now I'm fine with current functionality and doesn't have any plans for a next few months.