Improve JsonResource to Respect Selected Columns and Exclude Unselected Model Attributes

[MudassirAmeen]

When using Laravel’s JsonResource, all model attributes are included in the API response — even if the Eloquent query only selected a subset of columns using ->select(...).

This causes unexpected or unnecessary fields to appear in the final JSON. Consider:

$users = User::select('id', 'name')->get();
return UserResource::collection($users);

The above will still output all columns (email, created_at, etc.) if they exist in the model, because JsonResource accesses model properties directly (using $this->attribute or $this->{$key}), bypassing the original selection intent.

🎯 Why This Matters

• Data cleanliness: You want to send only what you explicitly queried.

• API optimization: Avoid unnecessary payload.

• Frontend integrity: Sometimes fields exist with intentional null values (e.g. email_verified_at), but Laravel outputs unset fields as null regardless of whether they were loaded.

• Security: Accidentally leaking unused model fields becomes easier.

• No error/warning: No exception is thrown when accessing unselected fields — only silent inclusion.

---

✅ Current Workaround

To solve this, I implemented a custom BaseResource that ensures only selected attributes and loaded relationships are included in the response:

<?php

namespace App\Http\Resources;

use Illuminate\Http\Request;
use Illuminate\Http\Resources\Json\JsonResource;
use Illuminate\Support\Facades\Log;

/**
 * Class BaseResource
 *
 * This abstract class provides a reusable way to structure JSON resources.
 * It maps model attributes and related resources using defined static arrays.
 */
abstract class BaseResource extends JsonResource
{
    /**
     * List of model properties to include in response.
     * @var array<string, array{key: string, default?: mixed}>
     */
    protected static array $fields = [];

    /**
     * List of relationships to include.
     * @var array<string, array{resource: class-string<JsonResource>, key: string}>
     */
    protected static array $relations = [];

    /**
     * Define any custom/computed fields to be appended.
     *
     * @return array
     */
    protected function customFields(): array
    {
        return [];
    }

    /**
     * Transform the resource into an array.
     *
     * @param  Request  $request
     * @return array
     */
    public function toArray(Request $request): array
    {
        Log::warning("1");
        // Check if resource is null before proceeding
        if ($this->resource === null)
        {
            return [];
        }
        // Map attributes with fallback defaults
        $attrs = collect(static::$fields)
            ->mapWithKeys(function (array $cfg, string $prop)
            {
                if (!array_key_exists($prop, $this->resource->getAttributes()))
                {
                    return [];
                }

                $val = $this->{$prop} ?? $cfg['default'] ?? null;
                return [$cfg['key'] => $val];
            })
            ->toArray();

        // Map relations only if loaded
        $rels = collect(static::$relations)
            ->filter(fn(array $cfg, string $rel) => $this->resource->relationLoaded($rel))
            ->mapWithKeys(function (array $cfg, string $rel)
            {
                $related = $this->{$rel};

                if ($related instanceof \Illuminate\Database\Eloquent\Collection)
                {
                    return [$cfg['key'] => $cfg['resource']::collection($related)];
                }
                elseif ($related instanceof \Illuminate\Database\Eloquent\Model)
                {
                    return [$cfg['key'] => new $cfg['resource']($related)];
                }
                else
                {
                    return [$cfg['key'] => null];
                }
            })
            ->toArray();

        // Merge everything into final resource array
        return array_merge($attrs, $rels, $this->customFields());
    }
}

Then you can define a concrete resource like this:

<?php
namespace App\Http\Resources\Party;

use App\Http\Resources\BaseResource;
use App\Http\Resources\ProductSetting\ProductStationResource;
use App\Http\Resources\Setting\AreaResource;
use App\Http\Resources\User\UserResource;

class PartyResource extends BaseResource
{
    protected static array $fields = [
        'iPartyID' => ['key' => 'party_id'],
        'iFirmID' => ['key' => 'firm_id'],
        'iSystemUserID' => ['key' => 'system_user_id'],
        'iFirmStationID' => ['key' => 'station_id'],
        // ...
    ];

    protected static array $relations = [
        'area' => [
            'resource' => AreaResource::class,
            'key' => 'area',
        ],
        // ...
    ];

    protected function customFields(): array
    {
        return [
            'status' => $this->bStatus ?? 'N/A',
            'sync_status' => $this->sSyncStatus ?? 'N/A',
            // ...
        ];
    }
}

---

💡 Feature Suggestion

Laravel could offer an optional feature or trait like:

use FiltersSelectedAttributes; // Hypothetical

public function toArray($request)
{
    return $this->onlySelectedAttributes(); // or similar
}

Or even an enhancement in JsonResource to respect $model->getAttributes() by default rather than directly accessing $this->{$key} blindly.

---

📌 Why Not Just Remove All Nulls?

We should not remove all null values — some are intentionally returned to the frontend to indicate "present but empty."
The goal is to exclude only the attributes that were never selected or loaded, not to cleanse all nulls.

---

🤝 Conclusion

This would make Laravel’s JsonResource system cleaner and smarter by design.
I’d love to hear community feedback on whether something like this could become part of the core, or possibly provided as a supported trait or helper.

Thanks for the great framework and community support! Love Laravel ❤️

[macropay-solutions]

@MudassirAmeen this is in fact an interesting finding that we would label as bug. But, maybe for consistency in responses to not break some clients that rely on the keys being there, it is not a bug but a feature. If you want this functionality you can use our crud lib free suite.

[MudassirAmeen]

@macropay-solutions Thanks for the response! I agree it’s important not to break client-side expectations. My suggestion was more towards having this behavior optionally enabled — either via a trait or a setting. In the meantime, I’ve implemented a reusable base resource that only includes selected columns and loaded relationships. Sharing this with the community might help others who prefer cleaner responses without unnecessary nulls.