مجلد routes

وكل عام وأنت بخير، 
مجلد routes في لارافيل هو المجلد الحاوي لمسارات التطبيق بما في ذلك مسارات تطبيق الويب. وعادة ما يحتوي الملفات التالية: 

1. web.php: ويتم فيها تصريح جميع المسارات التي تعنى بتطبيق الويب
2. api.php: يتم فيها تصريح مسارات واجهة التطبيق البرمجية
3. console.php: هو الملف الذي يتم فيه تصريح أوامر Artisan اضافية، مثال: 

   Artisan::command('test_command', function () {
       $this->comment('Hello From Hsoub Academy!');
   });

   ثم تشغيل الأمر: 

   php artisan test_command

   سوف يعطي:

   Hello From Hsoub Academy

   .

4. channels.php: هو ملف خاص بقنوات سوكيت التي يمكن استعمالها في التطبيق، ويتم فيه تصريح اسماء هاته القنوات ونوعها وأي خصائص اضافية لها.

من الملاحظ أن ملفي channels و console مختلفين عن باقي الملفات، غير أن web و api يتشابهان قليلا عدى أن كل من الملفين يتم التعامل معه بطريقة مختلفة للآخر ويتم تطبيق بعض الطبقات الوسيطة الاضافية في كل منهما. فمثلا في api يتم تطبيق مجموعة الطبقات الوسيطة api في حين أن web يتضمن مجموعة الطبقات الوسيطة web. مثلما هما مبيننان في ملف Kernel.php: 

protected $middlewareGroups = [
        'web' => [
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],

        'api' => [
            // \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
            \Illuminate\Routing\Middleware\ThrottleRequests::class.':api',
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],
    ];

كل طبقة وسيطة تتضمن آلية معينة تحدد طريقة التعامل مع المسارات المصرحة في أي من الملفين. مثال: 

• المسارات المحددة في ملف API لا تحتاج إلى حماية CSRF لأن هجمات CSRF (Cross-Site Request Forgery) تستهدف عادةً صفحات الويب حيث يمكن للمهاجم استغلال جلسة المستخدم لإجراء طلبات غير مصرح بها. في المقابل، تطبيقات API غالبًا ما تكون عديمة الحالة (stateless)، مما يعني أنها لا تحتفظ بأي معلومات عن حالة العميل بين الطلبات. لذا، لا يمكن تنفيذ هجمات CSRF عليها بنفس الطريقة التي تُنفذ على صفحات الويب، وبالتالي لا تتطلب حماية CSRF بنفس القدر. في لارافيل، تُحمى صفحات الويب باستخدام CSRF لأن الطلبات تأتي عادة من متصفح المستخدم، بينما لا تحتاج تطبيقات API لهذه الحماية لأن الطلبات تُرسل غالبًا من تطبيقات أخرى أو من جهة العميل بشكل مباشر. ولذلك نجد الطبقة الوسيطة VerifyCsrfToken في مجموعة الطبقات web في حين أنها غائبة في مجموعة الطبقات api

اخي عدنان بارك الله فيك علي الرد

بالمختصر هل web.php أضع بيه روابط موقع 

بتاريخ 28 دقائق مضت قال Adnane Kadri:

وكل عام وأنت بخير، 
مجلد routes في لارافيل هو المجلد الحاوي لمسارات التطبيق بما في ذلك مسارات تطبيق الويب. وعادة ما يحتوي الملفات التالية: 

1. web.php: ويتم فيها تصريح جميع المسارات التي تعنى بتطبيق الويب
2. api.php: يتم فيها تصريح مسارات واجهة التطبيق البرمجية
3. console.php: هو الملف الذي يتم فيه تصريح أوامر Artisan اضافية، مثال: 

   Artisan::command('test_command', function () {
       $this->comment('Hello From Hsoub Academy!');
   });

   ثم تشغيل الأمر: 

   php artisan test_command

   سوف يعطي:

   Hello From Hsoub Academy

   .

4. channels.php: هو ملف خاص بقنوات سوكيت التي يمكن استعمالها في التطبيق، ويتم فيه تصريح اسماء هاته القنوات ونوعها وأي خصائص اضافية لها.

من الملاحظ أن ملفي channels و console مختلفين عن باقي الملفات، غير أن web و api يتشابهان قليلا عدى أن كل من الملفين يتم التعامل معه بطريقة مختلفة للآخر ويتم تطبيق بعض الطبقات الوسيطة الاضافية في كل منهما. فمثلا في api يتم تطبيق مجموعة الطبقات الوسيطة api في حين أن web يتضمن مجموعة الطبقات الوسيطة web. مثلما هما مبيننان في ملف Kernel.php: 

protected $middlewareGroups = [
        'web' => [
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],

        'api' => [
            // \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
            \Illuminate\Routing\Middleware\ThrottleRequests::class.':api',
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],
    ];

كل طبقة وسيطة تتضمن آلية معينة تحدد طريقة التعامل مع المسارات المصرحة في أي من الملفين. مثال: 

• المسارات المحددة في ملف API لا تحتاج إلى حماية CSRF لأن هجمات CSRF (Cross-Site Request Forgery) تستهدف عادةً صفحات الويب حيث يمكن للمهاجم استغلال جلسة المستخدم لإجراء طلبات غير مصرح بها. في المقابل، تطبيقات API غالبًا ما تكون عديمة الحالة (stateless)، مما يعني أنها لا تحتفظ بأي معلومات عن حالة العميل بين الطلبات. لذا، لا يمكن تنفيذ هجمات CSRF عليها بنفس الطريقة التي تُنفذ على صفحات الويب، وبالتالي لا تتطلب حماية CSRF بنفس القدر. في لارافيل، تُحمى صفحات الويب باستخدام CSRF لأن الطلبات تأتي عادة من متصفح المستخدم، بينما لا تحتاج تطبيقات API لهذه الحماية لأن الطلبات تُرسل غالبًا من تطبيقات أخرى أو من جهة العميل بشكل مباشر. ولذلك نجد الطبقة الوسيطة VerifyCsrfToken في مجموعة الطبقات web في حين أنها غائبة في مجموعة الطبقات api

بتاريخ 6 دقائق مضت قال ايمن ميلاد:

اخي عدنان بارك الله فيك علي الرد

بالمختصر هل web.php أضع بيه روابط موقع 

بالضبط، به تستطيع تعريف مسارات الويب التي تتعامل مع مختلف أنواع الطلبات HTTP مثل GET, POST, PUT, DELETE، وغيرها، فكل مسار  يشير إلى وحدة تحكم Controller لمعالجة الطلب أو إلى دالة مغلقة Closure.

للتوضيح:

<?php

use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return view('welcome');
});

Route::post('/submit', 'FormController@submit');

أيضًا المسارات المحددة في web.php تُطبق عليها وسيط (Middleware) web بشكل افتراضي، والذي يتعامل مع الجلسات sessions وملفات تعريف الارتباط cookies، بالتالي هي مناسبة للصفحات التي تحتاج إلى تتبع حالة المستخدم، مثل صفحات تسجيل الدخول، سلال التسوق، إلخ.

بتاريخ 21 دقائق مضت قال Mustafa Suleiman:

بالضبط، به تستطيع تعريف مسارات الويب التي تتعامل مع مختلف أنواع الطلبات HTTP مثل GET, POST, PUT, DELETE، وغيرها، فكل مسار  يشير إلى وحدة تحكم Controller لمعالجة الطلب أو إلى دالة مغلقة Closure.

للتوضيح:

<?php

use Illuminate\Support\Facades\Route;

Route::get('/', function () {
    return view('welcome');
});

Route::post('/submit', 'FormController@submit');

أيضًا المسارات المحددة في web.php تُطبق عليها وسيط (Middleware) web بشكل افتراضي، والذي يتعامل مع الجلسات sessions وملفات تعريف الارتباط cookies، بالتالي هي مناسبة للصفحات التي تحتاج إلى تتبع حالة المستخدم، مثل صفحات تسجيل الدخول، سلال التسوق، إلخ.

و api.php ماذا أضع به

بتاريخ منذ ساعة مضت قال ايمن ميلاد:

و api.php ماذا أضع به

للتوضيح، ملف web.php هو لتعريف مسارات الويب العادية التي تتعامل مع الطلبات التي تأتي من المتصفحات، وتلك المسارات في العادة نستخدمها لتقديم صفحات HTML، وتعتمد على الجلسات sessions وحماية CSRF.

بينما ملف api.php الغرض منه تعريف مسارات واجهات برمجة التطبيقات APIs التي تتعامل مع الطلبات التي تأتي من تطبيقات العملاء أو الخدمات الأخرى وليس من المتصفحات بشكل مباشر، وذلك لإرجاع البيانات بصيغة JSON ولا تعتمد على الجلسات وحماية CSRF.

ومسارات الـ API تلك عديمة الحالة stateless، بمعنى أن كل طلب يتم معالجته بشكل مستقل عن الطلبات الأخرى، ولا يتم الاحتفاظ بأي معلومات عن المستخدم أو الطلب بين الطلبات المختلفة، فكل طلب يحتوي على جميع المعلومات اللازمة لمعالجته.

ومن ضمن وظائف الـ API توفير وظائف أو بيانات معينة لتطبيقات أو خدمات خارجية، مثلاً يستطيع تطبيق التجارة الإلكترونية أن يوفر واجهة API للسماح لتطبيقات الجوال بالوصول إلى قائمة المنتجات، معالجة الطلبات، وما إلى ذلك.