API Resource در Laravel چیست؟ آموزش ساخت و استفاده با مثال عملی

هنگام ساخت REST API در Laravel، یکی از موضوعات مهم این است که اطلاعات دیتابیس را با چه ساختاری به کلاینت ارسال کنیم. ممکن است در ابتدا بتوانیم مدل‌های Eloquent را مستقیماً به JSON تبدیل کنیم؛ اما با بزرگ‌تر شدن پروژه، کنترل ساختار پاسخ‌ها و جلوگیری از نمایش اطلاعات غیرضروری اهمیت بیشتری پیدا می‌کند.

برای حل این مسئله، لاراول قابلیتی به نام API Resource ارائه می‌دهد. با استفاده از Resource می‌توانیم مشخص کنیم چه فیلدهایی از یک مدل در خروجی API قرار بگیرند، داده‌ها با چه نام‌هایی نمایش داده شوند و روابط میان مدل‌ها چگونه در پاسخ JSON قرار گیرند.

در این مقاله یاد می‌گیریم API Resource چیست، چطور آن را ایجاد کنیم، چگونه برای یک مدل و مجموعه‌ای از مدل‌ها از آن استفاده کنیم و چطور خروجی API را برای پروژه‌های واقعی استاندارد کنیم.

API Resource در Laravel چیست؟

API Resource ابزاری در لاراول است که به ما اجازه می‌دهد نحوه تبدیل مدل‌ها و داده‌های برنامه به خروجی مناسب API را کنترل کنیم.

فرض کنید یک مدل به نام User دارید که اطلاعات زیر را در دیتابیس نگهداری می‌کند:

• شناسه کاربر
• نام
• ایمیل
• رمز عبور هش‌شده
• تاریخ ایجاد حساب
• تاریخ آخرین ویرایش

اگر اطلاعات مدل را بدون طراحی مشخصی به API برگردانید، ممکن است خروجی شما شامل فیلدهایی شود که نیازی به نمایش آن‌ها ندارید یا قرارداد پاسخ API را بیش از حد به ساختار داخلی مدل وابسته کند.

با API Resource می‌توانید دقیقاً تعیین کنید که کلاینت چه اطلاعاتی دریافت کند.

برای مثال، ممکن است بخواهید پاسخ API فقط چنین ساختاری داشته باشد:

{

    "data": {

        "id": 10,

        "name": "Ali",

        "email": "ali@example.com"

    }

}

در این ساختار، اطلاعاتی مانند رمز عبور هش‌شده در پاسخ قرار نمی‌گیرند و توسعه‌دهنده کنترل بیشتری بر خروجی دارد.

البته API Resource به‌تنهایی جایگزین امنیت، احراز هویت یا کنترل دسترسی نیست؛ بلکه ابزاری برای شکل‌دهی به داده‌های خروجی است.

چرا باید از API Resource استفاده کنیم؟

استفاده از Resource در پروژه‌های کوچک اختیاری است، اما در پروژه‌هایی که APIهای متعددی دارند، می‌تواند مزایای مهمی داشته باشد.

۱. کنترل فیلدهای خروجی

می‌توانید مشخص کنید چه اطلاعاتی به کلاینت ارسال شود و چه فیلدهایی در پاسخ قرار نگیرند.

۲. یکسان‌سازی ساختار پاسخ‌ها

اگر چند مسیر مختلف اطلاعات محصولات را برمی‌گردانند، می‌توانید خروجی آن‌ها را براساس یک ساختار مشخص طراحی کنید.

۳. جداسازی مدل از قرارداد API

ممکن است ساختار دیتابیس در آینده تغییر کند؛ اما نخواهید پاسخ API برای تمام کلاینت‌ها تغییر کند. Resource به شما اجازه می‌دهد نحوه نمایش داده‌ها را جداگانه مدیریت کنید.

۴. مدیریت روابط بین مدل‌ها

می‌توانید روابطی مانند دسته‌بندی محصول، نویسنده مقاله یا سفارش‌های کاربر را در خروجی API نمایش دهید.

۵. مدیریت مجموعه داده‌ها و صفحه‌بندی

Resource می‌تواند برای یک مدل، مجموعه‌ای از مدل‌ها و نتایج صفحه‌بندی‌شده استفاده شود.

۶. ساده‌تر شدن نگهداری کد

به‌جای تکرار منطق تبدیل داده‌ها در چند Controller، می‌توانید این منطق را در یک Resource متمرکز کنید.

پیش‌نیازهای استفاده از API Resource

برای درک بهتر مثال‌ها، آشنایی با مفاهیم زیر مفید است:

• مدل‌های Eloquent
• Controller و Route
• ساختار JSON
• ارتباط میان مدل‌ها
• ساخت REST API در Laravel

اگر هنوز با این مفاهیم آشنا نیستید، ابتدا مقاله‌های آموزش Eloquent در Laravel، آموزش Controller در Laravel و آموزش ساخت REST API در Laravel را مطالعه کنید.

مثال‌های این مقاله با ساختار رایج نسخه‌های جدید لاراول نوشته شده‌اند. ممکن است جزئیات برخی امکانات در نسخه‌های قدیمی‌تر متفاوت باشد.

مرحله اول: ساخت API Resource در Laravel

برای ساخت یک Resource با نام ProductResource، دستور زیر را اجرا کنید:

php artisan make:resource ProductResource

پس از اجرای دستور، فایل زیر ایجاد می‌شود:

app/Http/Resources/ProductResource.php

ساختار اولیه فایل معمولاً شبیه نمونه زیر است:

<?php



namespace App\Http\Resources;



use Illuminate\Http\Request;

use Illuminate\Http\Resources\Json\JsonResource;



class ProductResource extends JsonResource

{

    /**

     * Transform the resource into an array.

     */

    public function toArray(Request $request): array

    {

        return parent::toArray($request);

    }

}

کلاس ProductResource از JsonResource ارث‌بری می‌کند. این کلاس پایه امکانات موردنیاز برای تبدیل داده‌ها به پاسخ JSON را فراهم می‌کند.

مهم‌ترین قسمت این فایل، متد toArray است. در این متد مشخص می‌کنیم که اطلاعات خروجی چه ساختاری داشته باشند.

مرحله دوم: تعریف ساختار خروجی محصول

فرض کنید مدل Product شامل فیلدهای زیر است:

• id
• name
• description
• price
• is_active
• created_at
• updated_at

اکنون می‌خواهیم فقط فیلدهای موردنیاز را در خروجی API قرار دهیم.

فایل ProductResource.php را به شکل زیر تغییر دهید:

<?php



namespace App\Http\Resources;



use Illuminate\Http\Request;

use Illuminate\Http\Resources\Json\JsonResource;



class ProductResource extends JsonResource

{

    public function toArray(Request $request): array

    {

        return [

            'id' => $this->id,

            'name' => $this->name,

            'description' => $this->description,

            'price' => $this->price,

            'is_active' => $this->is_active,

            'created_at' => $this->created_at,

        ];

    }

}

در این کد، $this به منبعی اشاره می‌کند که Resource در حال تبدیل آن است؛ در این مثال، منبع یک مدل Product است.

برای نمونه، اگر اطلاعات محصول در دیتابیس به این شکل باشد:

id: 15

name: Mechanical Keyboard

description: Keyboard for programming

price: 2500000

is_active: 1

خروجی Resource تقریباً به این صورت خواهد بود:

{

    "data": {

        "id": 15,

        "name": "Mechanical Keyboard",

        "description": "Keyboard for programming",

        "price": "2500000.00",

        "is_active": true,

        "created_at": "2026-10-10T10:30:00.000000Z"

    }

}

مقادیر دقیق خروجی به داده‌های واقعی، تنظیمات Cast مدل و نحوه سریال‌سازی تاریخ‌ها بستگی دارند. برای مثال، اگر فیلد قیمت با Cast از نوع decimal:2 تعریف شده باشد، ممکن است به‌صورت رشته‌ای با دو رقم اعشار نمایش داده شود.

نکته مهم این است که Resource به ما اجازه می‌دهد فیلدها را با نام و قالب موردنظرمان ارائه کنیم.

مرحله سوم: استفاده از Resource در Controller

بعد از ساخت Resource، باید آن را در Controller فراخوانی کنیم.

برای مثال، اگر می‌خواهیم جزئیات یک محصول را نمایش دهیم، می‌توانیم متد show را به شکل زیر بنویسیم:

<?php



namespace App\Http\Controllers\Api;



use App\Http\Controllers\Controller;

use App\Http\Resources\ProductResource;

use App\Models\Product;



class ProductController extends Controller

{

    public function show(Product $product): ProductResource

    {

        return new ProductResource($product);

    }

}

در این مثال، ابتدا لاراول با استفاده از Route Model Binding محصول موردنظر را پیدا می‌کند. سپس مدل به ProductResource داده می‌شود تا به ساختار تعریف‌شده تبدیل شود.

اگر Route زیر را داشته باشیم:

Route::get('/products/{product}', [

    ProductController::class,

    'show',

]);

درخواست زیر اطلاعات محصول را برمی‌گرداند:

GET /api/products/15

Accept: application/json

پاسخ به‌طور پیش‌فرض در قالب یک شیء JSON با کلید data ارائه می‌شود.

این کلید بخشی از ساختار معمول پاسخ Resource در لاراول است. اگر قصد دارید ساختار متفاوتی داشته باشید، باید تنظیمات مربوط به Resource و پاسخ API را آگاهانه مدیریت کنید.

مرحله چهارم: استفاده از Resource برای فهرست محصولات

در پروژه‌های واقعی معمولاً لازم است علاوه بر نمایش یک محصول، فهرست محصولات را نیز برگردانیم.

برای این کار، می‌توانیم مجموعه‌ای از محصولات را به ProductResource::collection بدهیم.

<?php



namespace App\Http\Controllers\Api;



use App\Http\Controllers\Controller;

use App\Http\Resources\ProductResource;

use App\Models\Product;



class ProductController extends Controller

{

    public function index()

    {

        $products = Product::query()

            ->where('is_active', true)

            ->latest()

            ->get();



        return ProductResource::collection($products);

    }

}

در این کد، ابتدا محصولات فعال از دیتابیس دریافت می‌شوند و سپس هر محصول با استفاده از ProductResource به خروجی تبدیل می‌شود.

نمونه پاسخ:

{

    "data": [

        {

            "id": 15,

            "name": "Mechanical Keyboard",

            "description": "Keyboard for programming",

            "price": "2500000.00",

            "is_active": true,

            "created_at": "2026-10-10T10:30:00.000000Z"

        },

        {

            "id": 16,

            "name": "Gaming Mouse",

            "description": "Wireless mouse",

            "price": "1200000.00",

            "is_active": true,

            "created_at": "2026-10-09T10:30:00.000000Z"

        }

    ]

}

در این مثال، هر عضو آرایه data با ساختار تعریف‌شده در Resource نمایش داده می‌شود.

نکته مهم: استفاده از get() برای تمام رکوردها در جدول‌های بزرگ ممکن است منابع زیادی مصرف کند. در APIهایی که تعداد محصولات زیاد است، بهتر است از صفحه‌بندی استفاده کنید.

مرحله پنجم: استفاده از API Resource همراه با Pagination

صفحه‌بندی یکی از قابلیت‌های مهم API است. فرض کنید فروشگاه شما هزاران محصول دارد. دریافت همه محصولات در یک درخواست می‌تواند زمان پاسخ را افزایش دهد و فشار بیشتری به سرور وارد کند.

برای حل این مشکل، می‌توانیم از متد paginate استفاده کنیم:

public function index()

{

    $products = Product::query()

        ->where('is_active', true)

        ->latest()

        ->paginate(15);



    return ProductResource::collection($products);

}

در این حالت، هر صفحه حداکثر ۱۵ محصول دارد و لاراول اطلاعات مربوط به صفحه‌بندی را نیز در پاسخ ارائه می‌کند.

نمونه‌ای از ساختار پاسخ:

{

    "data": [

        {

            "id": 15,

            "name": "Mechanical Keyboard",

            "price": "2500000.00"

        }

    ],

    "links": {

        "first": "https://example.com/api/products?page=1",

        "last": "https://example.com/api/products?page=8",

        "prev": null,

        "next": "https://example.com/api/products?page=2"

    },

    "meta": {

        "current_page": 1,

        "last_page": 8,

        "per_page": 15,

        "total": 120

    }

}

این JSON صرفاً نمونه‌ای از ساختار پاسخ است؛ مقادیر واقعی به تعداد رکوردها و تنظیمات صفحه‌بندی بستگی دارند.

کلاینت می‌تواند از لینک صفحه بعد یا پارامتر page برای دریافت صفحه بعدی استفاده کند.

اگر به‌جای paginate از simplePaginate استفاده کنید، ساختار صفحه‌بندی ساده‌تری دریافت خواهید کرد که برای مواردی که تعداد کل رکوردها لازم نیست، مفید است.

برای اطلاعات بیشتر، مقاله آموزش Pagination در Laravel را مطالعه کنید.

مرحله ششم: تغییر نام فیلدها در خروجی API

یکی از مزایای Resource این است که می‌توانید نام فیلدهای خروجی را مستقل از نام ستون دیتابیس انتخاب کنید.

فرض کنید در دیتابیس فیلدی با نام is_active دارید، اما در قرارداد API می‌خواهید این فیلد با نام active ارسال شود.

کافی است Resource را به شکل زیر تغییر دهید:

public function toArray(Request $request): array

{

    return [

        'id' => $this->id,

        'name' => $this->name,

        'active' => $this->is_active,

    ];

}

اکنون پاسخ API شامل فیلد active خواهد بود و لازم نیست نام ستون دیتابیس را تغییر دهید.

این روش زمانی مفید است که می‌خواهید خروجی API خواناتر باشد یا قرارداد مشخصی برای نام‌گذاری فیلدها داشته باشید.

همچنین می‌توانید مقدارهای محاسبه‌شده را در خروجی قرار دهید:

public function toArray(Request $request): array

{

    return [

        'id' => $this->id,

        'name' => $this->name,

        'price' => $this->price,

        'is_expensive' => $this->price >= 10000000,

    ];

}

در این مثال، فیلد is_expensive مستقیماً از یک ستون دیتابیس خوانده نمی‌شود، بلکه براساس قیمت محاسبه می‌شود.

البته اگر محاسبات پیچیده یا سنگین باشند، بهتر است منطق مربوط به آن‌ها را به بخش مناسب‌تری از برنامه منتقل کنید.

مرحله هفتم: نمایش روابط مدل‌ها در API Resource

در بسیاری از پروژه‌ها، داده‌ها به‌صورت مستقل ذخیره نمی‌شوند. برای مثال، هر محصول ممکن است به یک دسته‌بندی تعلق داشته باشد.

فرض کنید مدل Product رابطه‌ای به نام category دارد و مدل Category نیز دارای Resource مخصوص خود است.

ابتدا Resource دسته‌بندی را ایجاد کنید:

php artisan make:resource CategoryResource

سپس ساختار خروجی آن را مشخص کنید:

<?php



namespace App\Http\Resources;



use Illuminate\Http\Request;

use Illuminate\Http\Resources\Json\JsonResource;



class CategoryResource extends JsonResource

{

    public function toArray(Request $request): array

    {

        return [

            'id' => $this->id,

            'name' => $this->name,

        ];

    }

}

اکنون می‌توانید در ProductResource، دسته‌بندی محصول را نیز نمایش دهید:

use App\Http\Resources\CategoryResource;



public function toArray(Request $request): array

{

    return [

        'id' => $this->id,

        'name' => $this->name,

        'price' => $this->price,



        'category' => new CategoryResource(

            $this->whenLoaded('category')

        ),

    ];

}

در اینجا از whenLoaded استفاده کرده‌ایم تا رابطه فقط زمانی در خروجی قرار بگیرد که قبلاً بارگذاری شده باشد.

برای اینکه دسته‌بندی همراه محصول دریافت شود، می‌توانیم از Eager Loading استفاده کنیم:

$products = Product::query()

    ->with('category')

    ->paginate(15);



return ProductResource::collection($products);

در این مثال فرض شده است رابطه category در مدل Product تعریف شده است.

استفاده از with می‌تواند از اجرای تعداد زیادی Query جداگانه برای دریافت روابط جلوگیری کند. این موضوع به‌ویژه در فهرست‌های طولانی اهمیت دارد و به کاهش مشکل N+1 کمک می‌کند.

برای آشنایی بیشتر با این مفهوم، مقاله آموزش Relationship در Laravel را مطالعه کنید.

مرحله هشتم: نمایش فیلدهای شرطی در Resource

گاهی لازم است یک فیلد فقط در شرایط خاصی نمایش داده شود.

برای مثال، ممکن است بخواهید فیلد internal_note فقط در صورتی در خروجی قرار بگیرد که از قبل بارگذاری شده باشد یا درخواست‌کننده مجوز لازم را داشته باشد.

یکی از امکانات Resource، متد when است:

public function toArray(Request $request): array

{

    return [

        'id' => $this->id,

        'name' => $this->name,



        'internal_note' => $this->when(

            $request->user()?->can('viewInternalNote', $this->resource),

            $this->internal_note

        ),

    ];

}

در این مثال، فرض شده است مجوزی به نام viewInternalNote برای مدل محصول تعریف شده باشد.

اگر کاربر مجوز لازم را نداشته باشد، فیلد موردنظر در خروجی قرار نمی‌گیرد.

این نمونه نشان می‌دهد که Resource می‌تواند برای نمایش شرطی داده‌ها استفاده شود؛ اما بررسی مجوز باید با سیاست‌های دسترسی مناسب و در بخش‌های مربوط به امنیت برنامه نیز انجام شود. صرفاً مخفی کردن یک فیلد در خروجی، جایگزین کنترل دسترسی به عملیات حساس نیست.

برای فیلدهایی که فقط در صورت بارگذاری رابطه باید نمایش داده شوند، از whenLoaded استفاده کنید. برای فیلدهای شرطی نیز می‌توانید از when یا امکانات مشابه Resource بهره ببرید.

مرحله نهم: استفاده از Resource برای پاسخ ایجاد و ویرایش

فرض کنید کاربر درخواست ایجاد محصول را ارسال کرده و اعتبارسنجی اطلاعات نیز موفق بوده است.

به‌جای اینکه مدل را مستقیماً برگردانیم، می‌توانیم از ProductResource استفاده کنیم:

use App\Http\Resources\ProductResource;

use App\Models\Product;

use Illuminate\Http\Request;



public function store(Request $request)

{

    $validated = $request->validate([

        'name' => ['required', 'string', 'max:255'],

        'description' => ['nullable', 'string'],

        'price' => ['required', 'numeric', 'min:0'],

        'is_active' => ['sometimes', 'boolean'],

    ]);



    $product = Product::create($validated);



    return (new ProductResource($product))

        ->response()

        ->setStatusCode(201);

}

در این روش، خروجی ایجاد محصول با همان ساختار تعریف‌شده در Resource ارائه می‌شود و کد وضعیت HTTP نیز روی 201 Created قرار می‌گیرد.

برای ویرایش محصول نیز می‌توانید از همین الگو استفاده کنید:

public function update(Request $request, Product $product)

{

    $validated = $request->validate([

        'name' => ['sometimes', 'required', 'string', 'max:255'],

        'description' => ['sometimes', 'nullable', 'string'],

        'price' => ['sometimes', 'required', 'numeric', 'min:0'],

        'is_active' => ['sometimes', 'boolean'],

    ]);



    $product->update($validated);



    return new ProductResource($product->refresh());

}

در اینجا refresh() مدل را از دیتابیس دوباره بارگذاری می‌کند تا پاسخ شامل مقادیر ذخیره‌شده فعلی باشد.

در یک پروژه واقعی، علاوه بر اعتبارسنجی باید مجوز ایجاد و ویرایش محصول را نیز بررسی کنید. همچنین بهتر است برای درخواست‌های پیچیده‌تر، قوانین اعتبارسنجی را به Form Request منتقل کنید.

مرحله دهم: تفاوت API Resource و JsonResponse چیست؟

هر دو ابزار می‌توانند برای برگرداندن پاسخ JSON استفاده شوند، اما کاربرد آن‌ها یکسان نیست.

برای مثال، پاسخ ساده زیر را می‌توان با JsonResponse ساخت:

return response()->json([

    'message' => 'درخواست با موفقیت انجام شد.',

]);

اما برای نمایش ساختاریافته یک محصول، استفاده از Resource می‌تواند خواناتر و قابل نگهداری‌تر باشد:

return new ProductResource($product);

این دو ابزار رقیب یکدیگر نیستند. می‌توانید در یک پروژه از هر دو استفاده کنید؛ مهم این است که برای هر نوع پاسخ، روش مناسبی انتخاب کنید.

مرحله یازدهم: مدیریت خطاها در کنار API Resource

API Resource مسئول اصلی مدیریت خطاهای برنامه نیست. وظیفه آن تبدیل داده‌ها به خروجی مشخص است.

برای مثال، اگر محصولی با شناسه موردنظر وجود نداشته باشد، ممکن است لاراول پاسخ 404 Not Found برگرداند. اگر اعتبارسنجی شکست بخورد، پاسخ خطای اعتبارسنجی ارائه می‌شود.

بنابراین باید میان دو موضوع تفاوت قائل شوید:

• Resource: شکل و ساختار داده‌های موفق را مشخص می‌کند.
• مدیریت خطا: نحوه پاسخ به درخواست‌های نامعتبر، منابع ناموجود و خطاهای داخلی را تعیین می‌کند.

اگر می‌خواهید خروجی خطاهای API نیز در تمام مسیرها ساختار یکسانی داشته باشد، می‌توانید قالب خطاها را در پیکربندی مدیریت استثناها و بخش‌های مناسب برنامه تنظیم کنید.

برای مثال، پاسخ خطای اعتبارسنجی می‌تواند شامل کد وضعیت 422 و فهرست خطاهای هر فیلد باشد. پاسخ مربوط به منبع ناموجود نیز معمولاً کد وضعیت 404 خواهد داشت.

از نمایش جزئیات داخلی خطا، Stack Trace و اطلاعات حساس در محیط عملیاتی خودداری کنید.

مرحله دوازدهم: بهترین روش‌ها برای استفاده از API Resource

برای استفاده حرفه‌ای از Resource در پروژه‌های Laravel، نکات زیر را رعایت کنید.

۱. فقط فیلدهای لازم را نمایش دهید

تمام فیلدهای مدل را بدون بررسی در خروجی قرار ندهید. ساختار خروجی باید براساس نیاز کلاینت و قرارداد API طراحی شود.

۲. Resourceهای قابل استفاده مجدد بسازید

اگر چند مسیر از ساختار یکسانی برای نمایش محصول استفاده می‌کنند، بهتر است از یک Resource مشترک بهره ببرید.

۳. روابط را آگاهانه بارگذاری کنید

از whenLoaded و Eager Loading استفاده کنید تا روابط فقط در زمان مناسب به خروجی اضافه شوند و تعداد Queryها بی‌دلیل افزایش پیدا نکند.

۴. ساختار پاسخ API را پایدار نگه دارید

اگر اپلیکیشن موبایل یا فرانت‌اند به نام فیلدهای خروجی وابسته است، تغییر نام یا حذف فیلدها می‌تواند باعث اختلال شود. تغییرات ناسازگار را با برنامه‌ریزی و در صورت نیاز با نسخه‌بندی API انجام دهید.

۵. منطق پیچیده را در Resource انباشته نکنید

Resource برای تبدیل داده‌ها مناسب است؛ اما منطق سنگین کسب‌وکار، عملیات مالی و محاسبات پیچیده بهتر است در بخش‌های مناسب دیگری از برنامه قرار بگیرند.

۶. امنیت را فقط به Resource وابسته نکنید

مخفی کردن فیلدها مفید است، اما مجوز دسترسی به عملیات و منابع باید در Policy، Gate، Middleware یا بخش‌های مناسب دیگر برنامه نیز بررسی شود.

۷. پاسخ‌ها را آزمایش کنید

با تست‌های خودکار یا ابزارهایی مانند Postman بررسی کنید که فیلدهای مورد انتظار وجود داشته باشند، فیلدهای حساس نمایش داده نشوند و ساختار خروجی در شرایط مختلف ثابت بماند.

سوالات متداول درباره API Resource در Laravel

API Resource در Laravel چه کاربردی دارد؟

API Resource برای تبدیل مدل‌ها و داده‌های برنامه به خروجی استاندارد JSON استفاده می‌شود. با آن می‌توانید فیلدهای خروجی، نام آن‌ها و نحوه نمایش روابط را کنترل کنید.

چگونه در Laravel یک API Resource بسازیم؟

از دستور زیر استفاده کنید:

php artisan make:resource ProductResource

سپس فایل ایجادشده در app/Http/Resources را باز کنید و ساختار خروجی را در متد toArray تعریف کنید.

تفاوت JsonResource و Resource::collection چیست؟

JsonResource معمولاً برای تبدیل یک منبع، مانند یک مدل، استفاده می‌شود. متد collection برای تبدیل مجموعه‌ای از منابع به کار می‌رود و می‌تواند با مجموعه‌های صفحه‌بندی‌شده نیز استفاده شود.

آیا استفاده از API Resource اجباری است؟

خیر. لاراول می‌تواند مدل‌ها و آرایه‌ها را مستقیماً به JSON تبدیل کند. بااین‌حال، Resource برای استانداردسازی خروجی و کنترل بهتر فیلدها در پروژه‌های متوسط و بزرگ بسیار مفید است.

آیا API Resource امنیت API را تضمین می‌کند؟

خیر. Resource کمک می‌کند اطلاعات غیرضروری در خروجی قرار نگیرند، اما جایگزین احراز هویت و مجوز دسترسی نیست. باید دسترسی کاربران به منابع و عملیات حساس را نیز کنترل کنید.

آیا API Resource از صفحه‌بندی پشتیبانی می‌کند؟

بله. می‌توانید مجموعه‌ای از مدل‌ها را با paginate دریافت کنید و آن را به ProductResource::collection بدهید. لاراول اطلاعات صفحه‌بندی را نیز در پاسخ ارائه می‌کند.

چگونه روابط مدل‌ها را در API Resource نمایش دهیم؟

می‌توانید از Resource مربوط به مدل مرتبط استفاده کنید و با whenLoaded نمایش رابطه را به بارگذاری آن وابسته کنید. برای جلوگیری از Queryهای اضافی نیز بهتر است از Eager Loading استفاده کنید.

جمع‌بندی

API Resource یکی از ابزارهای کاربردی Laravel برای طراحی خروجی‌های استاندارد و قابل نگهداری در REST API است. با استفاده از آن می‌توانید ساختار JSON را از مدل‌های دیتابیس جدا کنید، فیلدهای قابل نمایش را کنترل کنید، روابط را مدیریت کنید و پاسخ‌های فهرست و صفحه‌بندی‌شده را با قالب مشخص ارائه دهید.

در این مقاله، ساخت Resource، استفاده از آن در Controller، تبدیل یک مدل و مجموعه‌ای از مدل‌ها، مدیریت روابط، نمایش شرطی فیلدها و تفاوت Resource با JsonResponse را بررسی کردیم.

اگر در حال توسعه API برای فروشگاه اینترنتی، پنل مدیریت، سیستم SaaS یا اپلیکیشن موبایل هستید، یادگیری API Resource به شما کمک می‌کند خروجی‌های منظم‌تری طراحی کنید و تغییرات آینده پروژه را ساده‌تر مدیریت کنید.