آموزش API Laravel: ساخت ، مستند سازی و ایمن کردن یک API REST

این مقاله توسط> استیو مک دگال ، سازنده دیرینه> PHP/Laravel و دوست Zuplo نوشته شده است. تمام نظرات بیان شده خود اوست.

لاراول و زوپلو مسابقه ای است که در بهشت ​​ساخته شده است و هنوز هیچ کس از آن نمی داند. من فکر کردم اکنون زمان خوبی برای طی کردن چگونگی بالا بردن بازی API خود با لاراول و زوپلو با هم خواهد بود.

Zuplo خود مجموعه ای از ابزارهای غنی را ارائه می دهد که به شما در ساخت یک API شگفت انگیز کمک می کند ، و Laravel ، Laravel است! این یک چارچوب PHP تمام پشته است که به شما امکان می دهد به سرعت در مورد ایده ها تکرار کنید و برخی از موارد خوب را بسازید. با هم ، شما می توانید یک API بسازید که نه تنها شادی برای کار با آن است ، بلکه در حال توانمندسازی است.

ساخت مدل داده خود

من نمی خواستم API “یک Todo ™ ™ ️ ️” را بنویسم که شما نمی خواهید از آن چیزی برخوردار شوید. درعوض ، من تصمیم گرفتم که چتگپ را جدا کنم و یک جلسه طوفان مغزی داشته باشم. در میان آن ایده های معمول AI دیوانه وار ، یک گوهر ، Locallore API بود. بنابراین ، با ایده ای در جیب من و یک قهوه برای ادامه کار من – بیایید API را با استفاده از Laravel و Zuplo بسازیم که به کاربر اجازه می دهد داستان های کوتاه ارسال شده به مناطق محلی ارسال شود. بسیار جالب درست است؟ بیایید شروع کنیم

تمام پروژه های خوب لاراول با شروع می شوند laravel new، اما اخیراً با استفاده از Laravel Herd Pro تغییر کرده ام ، اکنون یک UI فانتزی دارم که می توانم این کار را انجام دهم. من هنوز هم دستورات را برای شما می نویسم ، فقط در صورتی که می خواهید دنبال کنید.

laravel new local-lore

ما قصد نداریم از هر کیت استارت برای این پروژه استفاده کنیم ، زیرا قطعاً به UI یا JavaScript احتیاج نداریم – و می خواهیم برای تولید کلیدهای API خود برای احراز هویت ، از Zuplo استفاده کنیم! پس از ایجاد این پروژه ، بیایید آن را در ویرایشگر کد مورد علاقه خود یا IDE باز کنیم.

ما قصد داریم از مدل کاربر و مهاجرت موجود استفاده کنیم – فقط چند تغییر جزئی برای تغییر از یک شناسه افزایش دهنده به ULID یا UUID ایجاد می کنیم.

Schema::create('users', static function (Blueprint $table): void {
    $table->ulid('id')->primary();

    $table->string('name');
    $table->string('email')->unique();
    $table->string('password');
    $table->rememberToken();

    $table->timestamp('email_verified_at')->nullable();
    $table->timestamps();
    $table->softDeletes();
});

همانطور که مشاهده می کنید ، مهاجرت کاربر جدا از کیفیت جزئی تنظیمات زندگی نسبتاً استاندارد باقی می ماند. بنابراین ، بیایید حرکت کنیم.

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

php artisan make:model Story -mf

این باعث می شود مدل داستان ، مهاجرت و کارخانه برای ما ایجاد شود. این مفید است زیرا همه چیز را برای مدیریت داستان های خود به ما می دهد و راهی برای ایجاد داستان برای مجموعه تست خود داریم. مدل داستان ما نسبتاً ساده است ، ما در تلاش نیستیم تا هر چیزی را در اینجا بسازیم:

Schema::create('story', static function (Blueprint $table): void {
    $table->ulid('id')->primary();

    $table->string('title');
    $table->string('status')->default(Status::Draft->value);

    $table->text('content');

    $table->decimal('latitude', 10, 7);
    $table->decimal('longitude', 10, 7);

    $table
        ->foreignUlid('user_id')
        ->index()
        ->constrained('users')
        ->cascadeOnDelete();

    $table->timestamp('published_at')->nullable();
    $table->timestamps();

    $table->index(['latitude', 'longitude']);
    $table->index('status');
});

ما ستون های عادی را که شما روی آن تأثیر می گذارید ، یک عنوان و محتوا و همچنین شناسه کاربر داریم. سپس ما یک وضعیت داریم ، که یک php enum است – یا پیش نویس یا منتشر شده. ما همچنین می خواهیم یک عرض جغرافیایی و طول جغرافیایی اضافه کنیم ، تا بتوانیم تا حد امکان محلی یا بیش از حد محلی باشیم. سپس Timestamp منتشر شده را اضافه می کنیم ، به طوری که وقتی داستان به روز می شود تا منتشر شود – تاریخ را علامت گذاری می کنیم.

در این مرحله ، ما موارد اصلی را که باید با کار واقعی API شروع کنیم ، داریم. قسمت سرگرم کننده! معمولاً من با تأیید اعتبار شروع می کنم ، اما به آن می رسم – همانطور که در آن جایی است که می خواهیم کد سفارشی را برای Zuplo ایجاد کنیم تا مطمئن شویم که به درستی کار می کند.

ایجاد نقاط پایانی API

من تمایل دارم که مسیرهایم را در پوشه های اصلی سازماندهی کنم routes دایرکتوری ، همانطور که به من امکان می دهد هنگام اسکن پرونده ها ، بار شناختی را کاهش دهم. بنابراین پرونده زیر را ایجاد کنید:

touch routes/api/routes.php routes/console/routes.php

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

// routes/api/routes.php
use Illuminate\Support\Facades\Route;

Route::prefix('stories')->as('stories:')->group(static function (): void {
    Route::post("https://dev.to/",)->name('create');
    Route::get('{story}',)->name('read');
    Route::patch('{story}',)->name('update');
    Route::delete('{story}',)->name('delete');
});

ما با پیشوند شروع می کنیم stories و نام گروهی از stories:* به طوری که در صورت نیاز می توانیم بعداً به داستانها مراجعه کنیم و به آنها پیوند دهیم. متوجه خواهید شد که من هنوز هیچ اقدامی را در مسیرها درج نکرده ام – این چیزی است که به زودی اضافه می کنم. اما اول ، من می خواستم یک ثانیه برای صحبت در مورد طرح صحبت کنم.

هدف از این API این است که به کاربران امکان ارسال ، به روزرسانی ، خواندن و جستجوی داستان ها را ارائه دهد. ما برای این کار نیازی به یک عمل شاخص نداریم. بنابراین ما API را به طور هدفمند کوتاه و در اینجا نگه می داریم. کاری که من معمولاً در یک API بزرگتر انجام می دهم ، تغییر آن برای استفاده از پرونده زیر است:

// routes/api/routes.php
use Illuminate\Support\Facades\Route;

Route::prefix('stories')->as('stories:')->group(base_path(
    path: 'routes/api/stories.php'
));

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

با این حال ، این API بسیار کوچک است ، بنابراین ما به تمام مسیرهای خود که در قسمت اصلی تعریف می شوند ، خواهیم چسبید routes/api/routes.php پرونده ای که قبلاً به آن نگاه کردیم من به جای وارد کردن هر کلاس اکشن مسیر فردی ، تمایل دارم فضای نام را برای منبع در بالا وارد کنم. بیایید نگاهی بیندازیم:

use App\Http\Controllers\Stories;
use Illuminate\Support\Facades\Route;

Route::prefix('stories')->as('stories:')->group(static function (): void {
    Route::post("https://dev.to/", Stories\CreateController::class)->name('create');
    Route::get('{story}', Stories\ReadController::class)->name('read');
    Route::patch('{story}', Stories\UpdateController::class)->name('update');
    Route::delete('{story}', Stories\DeleteController::class)->name('delete');
});

ما اکنون مسیرهای خود را به کنترل کننده ها پیوند داده ایم و این همه توسط چارچوب برای ما بارگذاری می شود. بیایید به کنترل کننده اولیه ، کنترلر Create نگاه کنیم. موردی که به کاربران امکان می دهد در واقع داستان ها را بسازند. برای انجام این کار ، ما می خواهیم ورودی کاربران را تأیید کنیم. بنابراین می توانیم با استفاده از خط فرمان artisan یک درخواست فرم ایجاد کنیم:

php artisan make:request Stories/CreateRequest

اعتبار سنجی درخواست لاراول

درخواست فرم ما مسئولیت اعتبار سنجی بار درخواست دریافتی را بر عهده دارد و اطمینان حاصل می کند که با مجموعه خاصی از قوانین مطابقت دارد. دلیل استفاده از درخواست فرم برای این امر ، به این دلیل است که از آنکه از ظرف DI برطرف شود – قبل از فراخوانی عمل کنترلر ، بار را تأیید می کند.

// app/Http/Requests/Stories/CreateRequest.php
final class CreateRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'title' => ['required', 'string', 'min:2', 'max:255'],
            'content' => ['nullable', 'string'],
            'latitude' => ['required', 'numeric', 'min:-90', 'max:90'],
            'longitude' => ['required', 'numeric', 'min:-180', 'max:180'],
        ];
    }
}

قوانین اعتبار سنجی لاراول واقعاً مفید هستند و بخشی از دلیل ساخت لاراول با آن بسیار آسان است. کاری که من تمایل به انجام آن دارم ، ایجاد یک بار بارگیری DTO است. این یک تلاش بیش از حد مهندسی است ، اما این بدان معنی است که هنگام برخورد با داده های درخواست ، من به جای یک آرایه PHP انعطاف پذیر ، با یک شی متنی و تایپ شده برخورد می کنم.

// app/Http/Payloads/Stories/CreatePayload.php
final readonly class CreatePayload
{
    public function __construct(
        public string $title,
        public null|string $content,
        public float $latitude,
        public float $longitude,
    ) {}
}

این یک شیء ساختاری به ما می دهد که می توانیم از برنامه خود استفاده کنیم که نه تنها زمینه آن را حفظ می کند بلکه نوع ایمنی مورد نیاز خود را نیز در برنامه خود حفظ می کند. بیایید روشی را به درخواست فرم خود اضافه کنیم ، که این امر را برای ما ایجاد می کند.

// app/Http/Requests/Stories/CreateRequest.php
final class CreateRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'title' => ['required', 'string', 'min:2', 'max:255'],
            'content' => ['nullable', 'string'],
            'latitude' => ['required', 'numeric', 'min:-90', 'max:90'],
            'longitude' => ['required', 'numeric', 'min:-180', 'max:180'],
        ];
    }

    public function payload(): CreatePayload
    {
        return new CreatePayload(
            title: $this->string('title')->toString(),
            content: $this->has('content')
                ? $this->string('content')->toString()
                : null,
            latitude: $this->float('latitude', null),
            longitude: $this->float('longitude', null),
        );
    }
}

هنگامی که درخواست فرم ما از ظرف حل شد و به کنترلر تزریق شد – می توانیم با آنها تماس بگیریم $request->payload() روش ایجاد یک نمونه جدید از CreatePayloadبشر

ایجاد یک کار صف

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

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

php artisan make:job CreateNewStory

هدف از این کار ، گرفتن درخواست بار و شناسه کاربر و ذخیره یک داستان جدید در پایگاه داده است.

final class CreateNewStory implements ShouldQueue
{
    use Queueable;

    public function __construct(
        public string $user,
        public readonly CreatePayload $payload,
    ) {}

    public function handle(DatabaseManager $database): void
    {
        $database->transaction(
            callback: fn() => Story::query()->create(
                attributes: array_merge(
                    $this->payload->toArray(),
                    ['user_id' => $this->user],
                ),
            ),
            attempts: 3,
        );
    }
}

از روش دسته ما در اینجا می توان برای تزریق وابستگی از ظرف ما به جای سازنده استفاده کرد. این به ما امکان تزریق DatabaseManager به جای استفاده از DB نمای سپس می توانیم معامله خود را شروع کنیم و با ادغام بار به عنوان یک آرایه و user_id برای نویسنده

بیایید اکنون به کنترل کننده های خود برگردیم و مطمئن شویم که ما این کار را در ما اعزام می کنیم CreateControllerبشر

final readonly class CreateController
{
    public function __construct(
        #[CurrentUser] private User $user,
        private Dispatcher $bus,
    ) {}

    public function __invoke(CreateRequest $request): Response
    {
        defer(
            callback: fn() => $this->bus->dispatch(
                command: new CreateNewStory(
                    user: $this->user->id,
                    payload: $request->payload(),
                ),
    ),
            name: 'create-stories',
        );

        return new JsonResponse(
            data: [
                'message' => 'We are processing your request.',
            ],
            status: Response::HTTP_ACCEPTED,
        );
    }
}

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

ایجاد مشخصات OpenAPI با تقلا

ما اکنون در نقطه‌ای هستیم که می توانم شما را با Zuplo معرفی کنم ، که به عنوان یک توسعه دهنده API کاملاً خارق العاده است. من می توانم از Zuplo به عنوان یک پروکسی واقع در Edge برای API خود استفاده کنم و قوانینی را برای API خود اعمال کنم که به جای کد در داشبورد Zuplo اداره می شوند. آیا می خواهید محدودیت نرخ را تغییر دهید؟ آیا می خواهید حافظه پنهان سنگین تری اضافه کنید؟ به استقرار لازم نیست.

برای شروع استفاده از Zuplo ، به مشخصات OpenAPI نیاز دارید که API شما را به خوبی توصیف می کند. در لاراول چند رویکرد مختلف وجود دارد که می توانید از آن استفاده کنید ، اما در این مقاله قصد دارم از بسته ای به نام Scramble استفاده کنم. Scramble ژنراتور اسناد OpenAPI برای Laravel است. این اسناد API را برای پروژه شما به طور خودکار ایجاد می کند بدون اینکه شما را به نوشتن حاشیه نویسی PHPDOC به صورت دستی بخواهید. استفاده از بسته نسبتاً ساده است ، بنابراین بیایید آن را با استفاده از آهنگساز نصب کنیم:

composer require dedoc/scramble

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

php artisan vendor:publish --provider="Dedoc\Scramble\ScrambleServiceProvider" --tag="scramble-config"

این یک ایجاد می کند config/scramble.php پرونده ما می خواهیم بخش هایی از این را به روز کنیم ، زیرا ما در API خود چند تغییر ایجاد کرده ایم.

return [
    'api_path' => 'api',
    'api_domain' => null,
    'export_path' => 'openapi.json',
    'info' => [
        'version' => env('API_VERSION', '0.0.1'),
                'description' => 'This is the OpenAPI Spec for the Local Lore API.',
         ],
];

پرونده پیکربندی حاوی چیزهای بیشتری از این است ، اما این تنها چیزی است که ما در حال حاضر باید به روز کنیم. یک قدم مهم که باید قبل از صادر کردن مشخصات OpenAPI خود بردارید ، تجزیه و تحلیل خروجی است. Scramble یک دستور مفید برای این کار دارد ، که یک اجرای خشک از صادرات شما را انجام می دهد و به شما اطلاع می دهد که آیا انتظار مشکلی دارد. می توانید با اجرای دستور artisan زیر از این دستور استفاده کنید:

php artisan scramble:analyze

اگر همه چیز خوب پیش می رود ، باید پیام زیر را ببینید:

همه چیز خوب است! مستندات بدون هیچ گونه خطایی ایجاد می شود

اگر این را می بینید ، مرحله بعدی صادر کردن مشخصات OpenAPI است. اگر این را نمی بینید ، پس باید مستندات تقلا و کد خود را بررسی کنید تا ببینید که آیا می توانید ببینید که چرا صادر نمی شود. بیایید فرض کنیم همه چیز مطابق آنچه انتظار می رود کار می کند ، و بیایید پرونده OpenAPI خود را اکنون با استفاده از دستور Artisan زیر صادر کنیم:

php artisan scramble:export

اکنون باید مشخصات OpenAPI صادر شده به ریشه پروژه خود داشته باشیم ، بیایید نگاهی گذرا به آنچه تولید کرده است – منهای مسیرها را به عنوان فضای زیادی به خود اختصاص دهیم!

{
  "openapi": "3.1.0",
  "info": {
    "title": "Local Lore API",
    "version": "0.0.1",
    "description": "This is the OpenAPI Spec for the Local Lore API."
  },
  "servers": [
    {
      "url": "https://local-lore.test/api"
    }
  ]
}

همانطور که مشاهده می کنید ، اطلاعاتی را که در پرونده پیکربندی تنظیم کرده ایم ، می کشد و ما را در حال کشیدن ماست APP_URL از ما .env پرونده برای آدرس سرور. در صورت نیاز به سفارشی کردن این ، می توانیم پیکربندی را به روز کنیم تا سرورهای مختلفی را که ممکن است داشته باشیم لیست کنیم.

اکنون می دانیم که این روند کار می کند ، بیایید نگاهی به درخواست پست برای ایجاد یک داستان جدید بیندازیم و ببینیم چه چیزی برای ما ایجاد شده است.

"\/stories": {
    "post": {
        "operationId": "stories:create",
        "tags": [
            "Create"
        ],
        "requestBody": {
            "required": true,
            "content": {
                "application\/json": {
                    "schema": {
                        "$ref": "#\/components\/schemas\/CreateRequest"
                    }
                }
            }
        },
        "responses": {
            "202": {
                "description": "",
                "content": {
                    "application\/json": {
                        "schema": {
                            "type": "object",
                            "properties": {
                                "message": {
                                    "type": "string",
                                    "example": "We are processing your request."
                                }
                            },
                            "required": [
                                "message"
                            ]
                        }
                    }
                }
            },
            "422": {
                "$ref": "#\/components\/responses\/ValidationException"
            }
        }
    }
}

این مسیر ، درخواست فرم ما و نحوه پاسخگویی ما را شناسایی کرده است. همچنین مؤلفه هایی را برای پاسخ و بدنه درخواست ایجاد کرده است – که واقعاً مفید است. یک مورد که من در مورد تلاش های قبلی برای تولید مشخصات Opanapi دوست نداشتم این است که آنها همه این موارد را درون خطی ایجاد می کنند ، و حفظ آن در طولانی مدت سخت تر می شود.

تنظیم دروازه zuplo خود

هنگامی که مشخصات OpenAPI خود را ایجاد کردیم ، می توانیم آن را به پروژه Zuplo خود وارد کرده و شروع کنیم!

پس از وارد کردن مشخصات (می توانید این کار را از طریق انجام دهید رمز > routes.oas.json > وارد کردن Openapi در پورتال Zuplo یا از طریق CLI در صورت توسعه محلی) ، می توانیم مسیری را که در ویرایشگر به آن اهمیت می دهیم انتخاب کنیم و شروع به اعمال خط مشی برای آن کنیم.

افزودن اعتبار سنجی درخواست API

در مرحله اول ، ما اعتبار سنجی درخواست را اضافه خواهیم کرد. این به شدت مورد نیاز نیست ، اما در صورت عدم تصویب قوانین اعتبار سنجی LARAVEL که در مشخصات OpenAPI قرار ندارند ، درخواست های آمدن به API ما را متوقف می کند.

در نقطه پایانی خود ، دکمه “+ افزودن خط مشی” را مشاهده خواهید کرد. روی آن کلیک کنید و “اعتبار سنجی درخواست” را جستجو کنید.

هنگامی که روی آن کلیک می کنید ، JSON را با برخی از گزینه ها مشاهده می کنید که در زیر “استفاده” شرح داده شده است.

{
  "export": "RequestValidationInboundPolicy",
  "module": "$import(@zuplo/runtime)",
  "options": {
    "includeRequestInLogs": false,
    "logLevel": "info",
    "validateBody": "reject-and-log",
    "validatePathParameters": "log-only",
    "validateQueryParameters": "log-only"
  }
}

برای اعمال خط مشی ، OK را کلیک کنید. بیایید پس انداز کنیم و آن را امتحان کنیم. روی “تست” و سپس “تست” را دوباره کلیک کنید و درخواست شما رد می شود.

شما نیاز به ساخت یک بدن JSON دارید که با ما مطابقت داشته باشد CreateRequest طرحواره از قبل – و همچنین تنظیم کنید Content-Type عنوان به application/jsonبشر در اینجا یک داستان نمونه برای شما وجود دارد:

{
  "title": "The Wild Hunt",
  "content": "The hunt went wild - forever!",
  "latitude": 0.0,
  "longitude": 0.0
}

پس از پر کردن هدر و بدنه – دوباره روی تست کلیک کنید.

موفقیت!

افزودن احراز هویت کلید API

بعد ، بیایید خط مشی احراز هویت کلید API را اضافه کنیم:

{
  "export": "ApiKeyInboundPolicy",
  "module": "$import(@zuplo/runtime)",
  "options": {
    "allowUnauthenticatedRequests": false,
    "cacheTtlSeconds": 60
  }
}

افزودن خط مشی در واقع جریان تنظیم کامل نیست (مستندات کامل را بررسی کنید) – اما این فقط برای نشان دادن اینکه چه عملکردی را می توان در دروازه انجام داد ، نشان می دهد.

اکنون ما تأیید می کنیم و اعتبار می دهیم. همه کارهایی که می توانیم در لاراول نیز انجام دهیم – اما این اتفاق قبل از اینکه به ما هدایت شود ، در لبه اتفاق می افتد ، به این معنی که کاربران سریعتر بازخورد فوری می گیرند و برنامه ما می تواند برای هرگونه درخواست که این سیاست ها را تصویب کند ، در دسترس بماند. به نظر می رسد که ما چک های خود را دو برابر می کنیم ، اما در واقعیت ما فقط درخواست هایی را که به هر حال شکست می خورند ، فیلتر می کنیم – نگه داشتن API ما برای درخواست هایی که موفق خواهند بود.

اضافه کردن محدودیت نرخ

یک خط مشی نهایی که من توصیه می کنم سیاست محدودیت نرخ باشد ، بله ما می توانیم این کار را در Laravel نیز انجام دهیم – اما این باعث می شود قبل از درخواست موفقیت آمیز ، چندین بار از تلاش برای درخواست و عدم موفقیت ، چندین بار جلوگیری کند. محدودیت نرخ نقض ، اگر بخواهد شکست بخورد ، ما تلاش های آنها را محدود خواهیم کرد. می توانید روی “اضافه کردن خط مشی” کلیک کرده و “محدود کردن نرخ” را جستجو کنید – در اینجا تنظیم پیش فرض که محدودیت های آن توسط IP است ، در هر دقیقه 2 درخواست اجازه می دهد:

{
  "export": "RateLimitInboundPolicy",
  "module": "$import(@zuplo/runtime)",
  "options": {
    "rateLimitBy": "ip",
    "requestsAllowed": 2,
    "timeWindowMinutes": 1
  }
}

مجدداً صفحه “تست” را باز کنید و 3 درخواست را آتش بزنید. شما باید نرخ محدود دریافت کنید.

بنابراین ، اکنون ما روش خوبی برای درخواست ما برای تأیید و تأیید اعتبار درخواست های دریافتی داریم. ما همچنین یک روش خوب برای پیشگویی در برابر مشخصات OpenAPI خود داریم و نرخ این تلاش ها را محدود می کنیم. نه تنها این ، بلکه Zuplo نیز به طور خودکار از DDOS محافظت می کند و باعث می شود API ما حتی ایمن تر و حتی امن تر از دنیای خارج باشد. تأخیر که از درخواست های حمل و نقل اضافه می کند بسیار حداقل است و با روشی که کار می کند ، چیزی نیست که شما یا کاربران خود متوجه آن شوید.

استفاده از API Laravel

اکنون که این همه وجود دارد ، ما می خواهیم API خود را مستقر کنیم. اکنون ، هنگامی که نوبت به استقرار API ها در لاراول می رسد ، رویکردهای مختلفی وجود دارد که می توانید از آنها استفاده کنید. Laravel Forge یک گزینه عالی است و به طور خودکار شما را برای زیرساخت های خود بر اساس وب سایت های GitHub مستقر می کند. گزینه دیگر استفاده از چیزی مانند Ploi.io است که شبیه به Laravel Forge است اما توسط یک شرکت متفاوت ساخته و نگهداری می شود. یک مورد که من در مورد PLOI دوست دارم ، این است که آنها بیش از استفاده از یک برنامه Laravel با چند ابزار اضافی سرمایه گذاری کرده اند. آنها به جزئیات بسیار خوبی در مورد چگونگی مدیریت مؤثر زیرساخت ها و برنامه های کاربردی خود از کنسول خود رفته اند.

اگر هیچ یک از این مواردی که شما به دنبال آن هستید ، نسخه آینده Laravel Cloud کامل خواهد بود. شما می توانید در کمتر از 60 ثانیه ، به یک زیرساخت مقیاس پذیر که توسط خود تیم لاراول کاملاً اداره می شود ، به اعزام صفر کاهش زمان برسید. از گزارش هایی که من دیده ام ، واقعاً به همان اندازه که به نظر می رسد خوب است – با این حال ، با امتحان کردن آن فقط می توانم تصریح کنم که چقدر خوب خواهد بود.

پیچیدن

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

من مطمئناً می دانم که API بعدی که من می سازم از Zuplo استفاده می کند تا به عنوان یک دروازه لبه برای پروژه من عمل کند تا من نه تنها شبانه با خوشحالی بخوابم بلکه عملکرد API خود را نیز بررسی می کنم. چرا آن را برای API بعدی خود امتحان نکنید؟