یوشا

دست نوشته ها و تجربیات شخصی

یوشا

دست نوشته ها و تجربیات شخصی

شهید دکتر مصطفی چمران: می گویند تقوا از تخصص لازمتر است، آنرا می پذیرم، اما می گویم آنکس که تخصص ندارد و کاری را می پذیرد بی تقواست!

طبقه بندی موضوعی
تبلیغات
Blog.ir بلاگ، رسانه متخصصین و اهل قلم، استفاده آسان از امکانات وبلاگ نویسی حرفه‌ای، در محیطی نوین، امن و پایدار bayanbox.ir صندوق بیان - تجربه‌ای متفاوت در نشر و نگهداری فایل‌ها، ۳ گیگا بایت فضای پیشرفته رایگان Bayan.ir - بیان، پیشرو در فناوری‌های فضای مجازی ایران

۲ مطلب با کلمه‌ی کلیدی «API» ثبت شده است

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

 

- نیاز نداشتن به API و تمرکز روی توسعه‌ی وب‌سایت

- کاهش پیچیدگی و تمیزکاری

- کاهش دردسرهای امنیتی

- بهبود مصرف منابع سرور

 

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

برای حذف اصولی API و موارد مرتبط از یک پروژه Laravel، باید مراحل زیر رو انجام داد:

 

1- حذف فایل API از Route ها

مسیرهای API معمولاً در فایل routes/api.php تعریف می‌شن. این فایل رو باید پاک کنید.

routes/api.php

 

2- حذف Loader فایل api.php در RouteServiceProvider

مسیر:

app/Providers/RouteServiceProvider.php

کدها:

public function boot()
{
    $this->routes(function () {
        // این قسمت رو حذف یا کامنت کنید
        // Route::middleware('api')
        //     ->prefix('api')
        //     ->group(base_path('routes/api.php'));

        Route::middleware('web')
            ->group(base_path('routes/web.php'));
    });
}

 

3- حذف middleware های مربوط به API در Kernel.php

مسیر:

app/Http/Kernel.php

کدها:

protected $middlewareGroups = [
    'web' => [
        // Middlewareهای وب
    ],

    // این قسمت رو حذف یا کامنت کنید
    // 'api' => [
    //     \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
    //     'throttle:api',
    //     \Illuminate\Routing\Middleware\SubstituteBindings::class,
    // ],
];

 

4- درصورت وجود: پاک کردن کنترلرها و منابع API

مسیر:

app/Http/Controllers/API
و
app/Http/Resources

 

5- پاک کردن cache ها

دستور زیر رو بزنید تا cache ها پاکسازی بشن:

php artisan optimize:clear

 

6- حذف دستورات پکیج Sanctum

مسیر:

app\Models\User.php

کدها:

   //use Laravel\Sanctum\HasApiTokens;

   final class User extends BaseUser
   {
      //use HasApiTokens;

اگر از این Trait در مسیرهای دیگه هم استفاده شده، حذفش کنید.

 

7- کانفیگ Path در CORS

مسیر:

config\cors.php

کدها:

'paths' => ['api/*', 'sanctum/csrf-cookie'], // -> 'paths' => [],

 

8- حذف فایل کانفیگ پکیج Sanctum و Passport

مسیر:

config\sanctum.php
و
config\passport.php

 

9- حذف کدهای Sanctum و Passport از داخل فایلهای tests

مسیر:

tests/unit/
و
tests/feature/

 

10- حذف کدها و جدول personal_access_tokens

جدول personal_access_tokens رو از دیتابیس حذف کنید. همچنین:

مسیر:

routes\console.php

کدها:

//DB::table('personal_access_tokens')->truncate();

 

11- نهایتاً حذف پکیج laravel/sanctum و laravel/passport

دستور:

composer remove laravel/sanctum
composer remove laravel/passport

و مجدد دستور زیر رو بزنید تا cache ها پاکسازی بشن:

php artisan optimize:clear
۰ نظر ۱۴۰۳/۰۹/۱۸
یوشا آل ایوب

1. Package Design Checklist

1.1. General

  • 1.1.1. Favor placing API and implementation into separate packages [explain]
  • 1.1.2. Favor placing APIs into high-level packages and implementation into lower-level packages [explain]
  • 1.1.3. Consider breaking up large APIs into several packages [explain]
  • 1.1.4. Consider putting API and implementation packages into separate Java archives [explain]
  • 1.1.5. Avoid (minimize) internal dependencies on implementation classes in APIs [explain]
  • 1.1.6. Avoid unnecessary API fragmentation [explain]
  • 1.1.7. Do not place public implementation classes in the API package [explain]
  • 1.1.8. Do not create dependencies between callers and implementation classes [explain]
  • 1.1.9. Do not place unrelated APIs into the same package [explain]
  • 1.1.10. Do not place API and SPI into the same package [explain]
  • 1.1.11. Do not move or rename the package of an already released public API [explain]

1.2. Naming

  • 1.2.1. Start package names with the company’s official root namespace [explain]
  • 1.2.2. Use a stable product or product family name at the second level of the package name [explain]
  • 1.2.3. Use the name of the API as the final part of the package name [explain]
  • 1.2.4. Consider marking implementation-only packages by including “internal” in the package name [explain]
  • 1.2.5. Avoid composite names [explain]
  • 1.2.6. Avoid using the same name for both package and class inside the package [explain]
  • 1.2.7. Avoid using “api” in package names [explain]
  • 1.2.8. Do not use marketing, project, organizational unit or geographic location names [explain]
  • 1.2.9. Do not use uppercase characters in package names [explain]
۰ نظر ۱۳۹۸/۱۰/۰۹
یوشا آل ایوب