شرح أفعال الـ HTTP (GET, POST, PUT, DELETE) والفرق بينها

مقدمة: لماذا فهم أفعال HTTP مهم في الأتمتة ودمج الأنظمة؟

عند بناء أي تكامل بين الأنظمة، سواء كان بين متجر إلكتروني ومنصة شحن، أو بين نظام تعليمي وأداة دفع، فإن أول ما يحدد شكل الاتصال هو نوع الطلب المستخدم داخل بروتوكول HTTP. كثيرون يحفظون أسماء GET وPOST وPUT وDELETE، لكن الاستخدام الصحيح لها هو ما يضمن أن تدفق البيانات يصبح واضحاً، قابلاً للصيانة، وآمناً.

إذا كنت قد قرأت سابقاً مقال فهم بروتوكول HTTP: رحلة البيانات من جهازك إلى السيرفر، فستعرف أن كل طلب يمر عبر مسار منظم يبدأ من العميل إلى الخادم ثم يعود باستجابة. أما هنا، فسنركّز على معنى كل فعل وكيف يغيّر سلوك API، ولماذا يؤثر اختياره على نجاح الأتمتة.

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

ما المقصود بأفعال HTTP؟

أفعال HTTP Methods هي التعليمات التي تخبر الخادم بما نريد فعله على مورد معيّن داخل Endpoint محدد. المورد قد يكون مستخدماً، طلباً، دورة تدريبية، فاتورة، أو أي سجل آخر موجود داخل قاعدة البيانات.

ولتفكيك الطلب بشكل أعمق، يمكنك الرجوع إلى مقال تشريح طلب الـ API: الـ Endpoint، الـ Headers، والـ Body، لأن الفعل وحده لا يعمل منفرداً، بل يأتي ضمن طلب يتضمن عنوان الاتصال، والترويسات، وأحياناً جسم الطلب أو Payload.

قاعدة مهمة في تصميم أي REST API: اختيار الفعل الصحيح يجعل التوثيق أوضح، ويسهّل على أي فريق آخر فهم سلوك الواجهة بدون قراءة الكود الداخلي للخادم.

شرح GET: جلب البيانات بدون تعديلها

يُستخدم GET لقراءة البيانات فقط. عند إرسال هذا النوع من الطلبات، فأنت تطلب من الخادم إرجاع معلومات موجودة مسبقاً بدون إنشاء أو تعديل أي شيء. لذلك يُعد الفعل الأكثر شيوعاً في لوحات التقارير، صفحات العرض، وعمليات التحقق قبل تنفيذ الأتمتة.

في الأتمتة، يُستخدم GET مثلاً لجلب بيانات طالب قبل تسجيله في دورة، أو للتحقق من حالة طلب قبل إصدار فاتورة، أو لاستخراج آخر السجلات التي وصلت من خدمة خارجية.

متى نستخدم GET؟

• عند استرجاع قائمة موارد مثل المستخدمين أو المنتجات.
• عند قراءة سجل واحد عبر معرّف محدد.
• عند تنفيذ خطوة تحقق داخل سيناريو أتمتة قبل الإرسال أو التحديث.
• عند بناء لوحات مراقبة تعتمد على القراءة فقط.

async function fetchStudent(studentId) {
  const response = await fetch(`https://api.example.com/students/${studentId}`, {
    method: 'GET',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
      'Accept': 'application/json'
    }
  });

  if (!response.ok) {
    throw new Error(`Request failed with status ${response.status}`);
  }

  return response.json();
}

شرح POST: إنشاء مورد جديد أو تشغيل إجراء

يُستخدم POST عادة لإنشاء مورد جديد داخل الخادم. عند إرسال بيانات عميل جديد، أو تسجيل طالب، أو إنشاء طلب شراء، فغالباً ما يكون هذا هو الفعل المناسب. ويتميز بأنه يرسل بيانات داخل Body ليعالجها الخادم.

كما يُستخدم أحياناً لتشغيل عمليات ليست مجرد إنشاء مباشر، مثل إرسال نموذج، تشغيل مهمة معالجة، أو استقبال إشعار من Webhook. لهذا يعتبر أكثر مرونة، لكنه يحتاج انضباطاً في التصميم حتى لا يتحول إلى فعل يُستخدم لكل شيء بلا منطق.

مثال عملي على POST في الأتمتة

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

async function createEnrollment(payload) {
  const response = await fetch('https://api.example.com/enrollments', {
    method: 'POST',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(payload)
  });

  if (!response.ok) {
    throw new Error(`Create failed with status ${response.status}`);
  }

  return response.json();
}

const payload = {
  studentId: 1452,
  courseId: 88,
  paymentStatus: 'paid'
};

توثيق نقطة اتصال نموذجي:
POST /enrollments
ينشئ تسجيلًا جديدًا للطالب داخل الدورة.
الحقول الإلزامية: studentId، courseId، paymentStatus.
الأخطاء الحرجة المحتملة: 400 عند نقص البيانات، 409 عند وجود تسجيل مكرر، 401 عند فشل Authentication.

شرح PUT: تحديث المورد بالكامل

يُستخدم PUT عندما تريد استبدال مورد موجود أو تحديثه بشكل كامل. المعنى العملي هنا أن العميل يرسل التمثيل الكامل للبيانات الجديدة، والخادم يعتمد هذه النسخة كمصدر نهائي للحالة الحالية.

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

ميزة مهمة: قابلية التكرار المنطقي

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

async function updateCustomer(customerId, payload) {
  const response = await fetch(`https://api.example.com/customers/${customerId}`, {
    method: 'PUT',
    headers: {
      'Authorization': 'Bearer YOUR_TOKEN',
      'Content-Type': 'application/json'
    },
    body: JSON.stringify(payload)
  });

  if (!response.ok) {
    throw new Error(`Update failed with status ${response.status}`);
  }

  return response.json();
}

شرح DELETE: حذف المورد أو تعطيله

الفعل DELETE يُستخدم لطلب إزالة مورد موجود. لكن في الأنظمة الاحترافية، الحذف لا يعني دائماً الإزالة الفعلية من قاعدة البيانات. أحياناً يتم تنفيذ ما يسمى Soft Delete عبر تعليم السجل كمعطل أو مؤرشف لحماية السجل التاريخي.

هذا مهم جداً في الأتمتة المرتبطة بالفواتير، الاشتراكات، والسجلات التعليمية، لأن الحذف غير المدروس قد يسبب فقدان بيانات مطلوبة للمراجعة أو الامتثال. لذلك يُفضّل دائماً فهم سياسة النظام قبل استخدام DELETE داخل أي سكربت.

مخاطر شائعة عند استخدام DELETE

• حذف سجلات مرتبطة بعلاقات لا يمكن استعادتها بسهولة.
• تشغيل الحذف على بيئة الإنتاج بدل بيئة الاختبار.
• عدم وجود تحقق مسبق من هوية المورد المستهدف.
• إهمال تسجيل العمليات داخل سجلات Audit Logs.

ما الفرق الجوهري بين GET وPOST وPUT وDELETE؟

الفرق الأساسي ليس في الاسم فقط، بل في نية العملية وتأثيرها على البيانات. GET يقرأ، POST ينشئ أو يطلق عملية، PUT يحدّث المورد بشكل كامل، وDELETE يزيله أو يعطله.

وعند تصميم تكامل احترافي، فإن هذا الوضوح يساعد في كتابة توثيق مفهوم، وإنشاء سياسات صلاحيات دقيقة، ومعالجة الأخطاء بشكل متوقع. كما أنه يسهل فهم سلوك الواجهة من قبل فرق أخرى، خاصة عند العمل على أكثر من نوع واجهات مثل REST أو GraphQL. وإذا أردت مقارنة أوسع بين الأنماط المختلفة، راجع الفرق بين REST و SOAP و GraphQL: متى نختار كل نوع؟.

كيف تختار الفعل الصحيح عند بناء سكربت أتمتة؟

في المشاريع الحقيقية، الاختيار الصحيح لا يبدأ من الكود، بل من السؤال: ما الذي أريد أن يحدث للبيانات؟ إذا كانت المهمة مجرد قراءة، استخدم GET. وإذا كنت تريد إنشاء سجل جديد، فاختر POST. أما إذا كانت هناك مزامنة شاملة لسجل معروف، فغالباً PUT هو الأنسب. والحذف لا ينبغي استخدامه إلا بعد فهم أثره التشغيلي والقانوني.

• ابدأ بفهم وظيفة Endpoint قبل كتابة أي سكربت.
• راجع التوثيق لتتأكد من الفعل المقبول لكل نقطة اتصال.
• افحص رموز الاستجابة مثل 200 و201 و404 و500.
• أضف آلية إعادة المحاولة فقط للعمليات التي تحتمل ذلك بأمان.
• سجّل كل خطوة مهمة لتسهيل تتبع الأخطاء في بيئات الإنتاج.

خاتمة

فهم أفعال HTTP ليس درساً نظرياً بسيطاً، بل هو أساس كل عملية تكامل ناجحة بين الأنظمة. عندما تستخدم GET وPOST وPUT وDELETE في أماكنها الصحيحة، يصبح سلوك النظام متوقعاً، ويقلّ خطر الأخطاء، وتصبح الأتمتة أكثر استقراراً وقابلية للتوسع.

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