When building an API with Laravel, retrieving data from the database is usually straightforward.

You create a model, write a query, return the result, and Laravel converts it into JSON.

But there is an important question that developers sometimes overlook:

Should your API expose your database models exactly as they are?

Imagine you are building a blog API. Your Article model contains several attributes:

  • id
  • title
  • slug
  • content
  • is_published
  • created_at
  • updated_at

Your frontend only needs the article's ID, title, slug, and publication date.

Should you return every database attribute anyway?

What happens when you later change your database structure? What if you need to include the author's information? What if different clients expect different response formats?

This is where Laravel API Resources become extremely useful.

In this article, we will explore what API Resources are, why they matter, and how to use them in a practical Laravel application.

1. The Problem: Returning Eloquent Models Directly

Consider a simple controller:

use App\Models\Article; class ArticleController extends Controller { public function index() { return Article::all(); } }

This works. Laravel automatically converts the Eloquent collection into a JSON response.

However, as your application grows, this approach can become difficult to manage.

For example:

  • You have limited control over the attributes exposed by the API.
  • Your response structure depends heavily on your database model.
  • You may unintentionally expose information that clients do not need.
  • Maintaining consistent responses across different endpoints becomes harder.
  • Adding relationships can make your responses increasingly complex.

The problem is not that returning Eloquent models is always wrong.

The problem is that your API response should be designed intentionally.

Your database structure and your public API structure do not necessarily have to be identical.

2. What Are Laravel API Resources?

Laravel API Resources provide a transformation layer between your Eloquent models and the JSON responses returned by your API.

In simple terms, they allow you to decide:

  • Which attributes should be returned.
  • How those attributes should be named.
  • Which relationships should be included.
  • How individual models and collections should be represented.

Think of an API Resource as a filter and presentation layer for your API data.

Instead of allowing your model to determine the entire response, you explicitly define what the client receives.

3. Creating Your First API Resource

Let's assume we already have an Article model.

Laravel provides an Artisan command to generate a resource:

php artisan make:resource ArticleResource

By default, Laravel creates the resource inside:

app/Http/Resources/ArticleResource.php

Open the generated file and define the attributes you want to expose.

namespace App\Http\Resources; use Illuminate\Http\Request; use Illuminate\Http\Resources\Json\JsonResource; class ArticleResource extends JsonResource { public function toArray(Request $request): array { return [ 'id' => $this->id, 'title' => $this->title, 'slug' => $this->slug, 'content' => $this->content, 'published_at' => $this->created_at, ]; } }

Notice something important:

We are not returning every attribute from the database.

We are explicitly defining the API response.

This gives us better control over what our application exposes.

4. Using the Resource in a Controller

Creating a resource is only the first step. We must also use it when returning data.

Let's update our controller.

For a single article:

use App\Http\Resources\ArticleResource; use App\Models\Article; public function show(Article $article) { return new ArticleResource($article); }

For a collection of articles:

public function index() { $articles = Article::all(); return ArticleResource::collection($articles); }

The collection() method allows Laravel to transform each article using the same resource definition.

Now, both endpoints follow a consistent response structure.

5. Understanding Resource Collections and Pagination

One of the most useful things about API Resources is how naturally they work with pagination.

Imagine your application has thousands of articles.

Returning all of them in one response is usually unnecessary and can affect performance.

Instead, use Laravel's pagination:

public function index() { $articles = Article::latest()->paginate(15); return ArticleResource::collection($articles); }

Laravel automatically provides pagination information alongside the transformed data.

A simplified response looks like this:

{ "data": [ { "id": 1, "title": "Understanding Laravel", "slug": "understanding-laravel", "content": "An introduction to Laravel...", "published_at": "2026-10-30T10:00:00.000000Z" } ], "links": { "first": "...", "last": "...", "prev": null, "next": "..." }, "meta": { "current_page": 1, "last_page": 4, "per_page": 15, "total": 52 } }

This is particularly useful when building APIs consumed by Vue.js, React, mobile applications, or other clients.

The frontend can display the articles and use the pagination metadata to navigate between pages.

You do not have to manually build all this pagination information.

6. Working with Relationships

Real-world applications rarely contain isolated models.

An article may belong to a user, have multiple comments, and belong to a category.

Let's say we want to include the author of each article in our API response.

First, define the relationship in your Article model:

public function author() { return $this->belongsTo(User::class, 'user_id'); }

Next, create a UserResource:

php artisan make:resource UserResource

Inside UserResource.php:

class UserResource extends JsonResource { public function toArray(Request $request): array { return [ 'id' => $this->id, 'name' => $this->name, ]; } }

Now, update ArticleResource:

use App\Http\Resources\UserResource; public function toArray(Request $request): array { return [ 'id' => $this->id, 'title' => $this->title, 'slug' => $this->slug, 'content' => $this->content, 'author' => new UserResource( $this->whenLoaded('author') ), ]; }

The whenLoaded() method is particularly important.

It tells Laravel to include the relationship only when it has already been loaded.

In your controller, you can explicitly load it:

public function index() { $articles = Article::with('author') ->latest() ->paginate(15); return ArticleResource::collection($articles); }

This approach helps you control relationship loading and avoid unnecessary database queries.

Important: whenLoaded() does not automatically solve the N+1 query problem. You still need to load the relationships appropriately, for example, with with().

7. Why Should You Use API Resources?

Let's summarize the practical benefits.

1. Control over exposed data

You decide exactly which attributes your API returns. This helps prevent unnecessary information from being exposed.

2. Consistent API responses

Different endpoints can follow a predictable structure, making frontend integration easier.

3. Better separation of responsibilities

Your models handle data and relationships, while resources handle the representation of that data in API responses.

4. Easier maintenance

Changes to your database structure do not necessarily require changes to the public API response.

5. Relationship management

You can control how related models are represented and when they appear in responses.

6. Pagination support

Resources work naturally with Laravel's pagination and provide useful metadata and navigation links.

8. A Few Best Practices

When working with API Resources, keep these points in mind:

  • Do not expose every database column automatically.
  • Create dedicated resources for related models when appropriate.
  • Use whenLoaded() for conditional relationships.
  • Eager-load relationships in your queries when you need them.
  • Use pagination for large collections.
  • Keep your response structure consistent.
  • Remember that API Resources do not replace authentication, authorization, or request validation.

The objective is not to create a resource class for every possible situation without thinking.

It is to use resources where they make your API clearer and easier to maintain.

Conclusion

Building an API is not just about retrieving information from a database and returning JSON.

It is also about deciding how that information should be presented, structured, and consumed by other applications.

Laravel API Resources provide a clean and practical way to achieve this.

They help developers build APIs that are easier to understand, integrate, and maintain as applications evolve.

If you are building APIs with Laravel and you are not using Resources yet, consider introducing them into your next project.

You may discover that a small architectural decision can make a significant difference in the long-term quality of your application.

Good APIs do not just return data. They return data with structure, consistency, and purpose.

What about you?

Do you use Laravel API Resources in your projects, or do you prefer returning Eloquent models directly?

I'd be interested in hearing about your approach and the reasons behind it.

Written by **Boris Aubin Simo* | Software Engineer*

Interested in software engineering, Laravel, application architecture, APIs, and digital innovation.