ما هو HTTP؟
بروتوكول نقل النص التشعبي (HTTP) مصمم لتمكين الاتصالات بين العملاء والخوادم. يعمل HTTP كبروتوكول طلب-استجابة بين العميل والخادم.
مثال: يرسل العميل (المتصفح) طلب HTTP إلى الخادم؛ ثم يرسل الخادم استجابة إلى العميل. تحتوي الاستجابة على معلومات الحالة حول الطلب وقد تحتوي أيضًا على المحتوى المطلوب.
طرق HTTP
- GET
- POST
- PUT
- HEAD
- DELETE
- PATCH
- OPTIONS
- CONNECT
- TRACE
أكثر طريقتين شيوعًا في HTTP هما: GET و POST.
طريقة GET
تُستخدم GET لطلب البيانات من مورد محدد. لاحظ أن سلسلة الاستعلام (أزواج الاسم/القيمة) تُرسل في عنوان URL لطلب GET:
/test/demo_form.php?name1=value1&name2=value2
بعض الملاحظات حول طلبات GET:
- يمكن تخزين طلبات GET مؤقتًا
- تبقى طلبات GET في سجل المتصفح
- يمكن وضع إشارة مرجعية على طلبات GET
- لا ينبغي أبدًا استخدام طلبات GET عند التعامل مع البيانات الحساسة
- طلبات GET لها قيود على الطول
- تُستخدم طلبات GET فقط لطلب البيانات (وليس تعديلها)
طريقة POST
تُستخدم POST لإرسال البيانات إلى خادم لإنشاء/تحديث مورد. يتم تخزين البيانات المرسلة إلى الخادم باستخدام POST في نص الطلب الخاص بطلب HTTP:
POST /test/demo_form.php HTTP/1.1 Host: w3schools.com
name1=value1&name2=value2
بعض الملاحظات حول طلبات POST:
- لا يتم تخزين طلبات POST مؤقتًا أبدًا
- لا تبقى طلبات POST في سجل المتصفح
- لا يمكن وضع إشارة مرجعية على طلبات POST
- طلبات POST ليس لها قيود على طول البيانات
مقارنة بين GET و POST
يقارن الجدول التالي بين طريقتي HTTP: GET و POST.
| الخاصية | GET | POST |
|---|---|---|
| زر الرجوع/إعادة التحميل | غير مضر | سيتم إعادة إرسال البيانات (يجب أن ينبه المتصفح المستخدم إلى أن البيانات على وشك إعادة الإرسال) |
| إمكانية وضع إشارة مرجعية | يمكن وضع إشارة مرجعية | لا يمكن وضع إشارة مرجعية |
| التخزين المؤقت | يمكن تخزينه مؤقتًا | لا يتم تخزينه مؤقتًا |
| نوع الترميز | application/x-www-form-urlencoded | application/x-www-form-urlencoded أو multipart/form-data. استخدم ترميز multipart للبيانات الثنائية |
| السجل | تبقى المعلمات في سجل المتصفح | لا يتم حفظ المعلمات في سجل المتصفح |
| قيود على طول البيانات | نعم، عند إرسال البيانات، تضيف طريقة GET البيانات إلى عنوان URL؛ وطول عنوان URL محدود (الحد الأقصى لطول عنوان URL هو 2048 حرفًا) | لا توجد قيود |
| قيود على نوع البيانات | يسمح فقط بالأحرف ASCII | لا توجد قيود. يُسمح أيضًا بالبيانات الثنائية |
| الأمان | GET أقل أمانًا مقارنة بـ POST لأن البيانات المرسلة جزء من عنوان URL |
لا تستخدم GET أبدًا عند إرسال كلمات المرور أو المعلومات الحساسة الأخرى! | POST أكثر أمانًا قليلاً من GET لأن المعلمات لا يتم تخزينها في سجل المتصفح أو في سجلات خادم الويب | | الرؤية | البيانات مرئية للجميع في عنوان URL | لا يتم عرض البيانات في عنوان URL |
طريقة PUT
تُستخدم PUT لإرسال البيانات إلى خادم لإنشاء/تحديث مورد. الفرق بين POST و PUT هو أن طلبات PUT مُتكررة. أي أن استدعاء نفس طلب PUT عدة مرات سينتج دائمًا نفس النتيجة. في المقابل، قد يؤدي استدعاء طلب POST بشكل متكرر إلى آثار جانبية تتمثل في إنشاء نفس المورد عدة مرات.
طريقة HEAD
HEAD مطابقة تقريبًا لـ GET، ولكن بدون نص الاستجابة. بمعنى آخر، إذا أعاد GET /users قائمة بالمستخدمين، فإن HEAD /users سيقوم بنفس الطلب ولكنه لن يُرجع قائمة المستخدمين.
يعد طلب HEAD مفيدًا للتحقق مما سيُرجعه طلب GET قبل إجراء طلب GET فعليًا – يمكن لطلب HEAD قراءة رأس Content-Length للتحقق من حجم الملف، دون تنزيل الملف فعليًا.
طريقة DELETE
تحذف طريقة DELETE المورد المحدد.
طريقة PATCH
تُستخدم طريقة PATCH لتطبيق تعديلات جزئية على مورد.
طريقة OPTIONS
تصف طريقة OPTIONS خيارات الاتصال للمورد الهدف.
طريقة CONNECT
تُستخدم طريقة CONNECT لبدء اتصال ثنائي الاتجاه (نفق) مع المورد المطلوب.
طريقة TRACE
تُستخدم طريقة TRACE لإجراء اختبار ارتداد الرسالة الذي يختبر المسار للمورد الهدف (مفيد لأغراض التصحيح).
