تطوير واجهات REST API

التعمق في أساليب HTTP ورموز الحالة

18 دقيقة الدرس 2 من 35

فهم أساليب HTTP بعمق

أساليب HTTP (تسمى أيضاً الأفعال) هي العمود الفقري لاتصالات واجهة برمجة REST. كل أسلوب له دلالات محددة وخصائص أمان وخصائص التكافؤ التي تحدد كيفية استخدامه. دعنا نستكشف كل أسلوب بالتفصيل.

ملاحظة: فهم الاستخدام الصحيح لأساليب HTTP أمر بالغ الأهمية لبناء واجهات برمجة REST التي تتبع معايير الصناعة وتكون بديهية للمطورين الآخرين للاستخدام.

GET - استرجاع الموارد

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

الخصائص:

  • آمن: لا يغير حالة الخادم
  • متكافئ: إجراء نفس الطلب عدة مرات ينتج نفس النتيجة
  • قابل للتخزين المؤقت: يمكن تخزين الاستجابات مؤقتاً بواسطة المتصفحات وCDNs
  • له جسم: لا يوجد جسم للطلب (يتم تمرير البيانات في URL)

حالات الاستخدام الشائعة:

// الحصول على جميع المستخدمين
GET /api/users
الاستجابة: 200 OK
[
  {"id": 1, "name": "أحمد"},
  {"id": 2, "name": "محمد"}
]

// الحصول على مستخدم واحد
GET /api/users/123
الاستجابة: 200 OK
{"id": 123, "name": "أحمد", "email": "ahmed@example.com"}

// الحصول مع معاملات الاستعلام (التصفية، الفرز، الترقيم)
GET /api/users?role=admin&sort=name&page=1&limit=20
الاستجابة: 200 OK
{
  "data": [...],
  "pagination": {
    "current_page": 1,
    "total_pages": 5,
    "total_items": 100
  }
}

// الحصول على الموارد المتداخلة
GET /api/users/123/posts
الاستجابة: 200 OK
[
  {"id": 1, "title": "منشوري الأول"},
  {"id": 2, "title": "منشور آخر"}
]
تحذير: لا تستخدم أبداً GET للعمليات التي تعدل البيانات. عناوين URL مثل GET /api/users/123/delete هي ممارسة سيئة وخطر أمني (يمكن تشغيلها بواسطة علامات الصور أو الجلب المسبق).

POST - إنشاء الموارد

يُستخدم POST لإنشاء موارد جديدة على الخادم. يرسل البيانات في جسم الطلب ويعيد عادةً المورد المُنشأ مع رمز الحالة 201.

الخصائص:

  • غير آمن: يغير حالة الخادم
  • غير متكافئ: طلبات متطابقة متعددة تنشئ موارد متعددة
  • غير قابل للتخزين المؤقت: افتراضياً (يمكن جعله قابلاً للتخزين المؤقت مع الرؤوس المناسبة)
  • له جسم: نعم - البيانات مرسلة في جسم الطلب

إنشاء الموارد:

POST /api/users
Content-Type: application/json

{
  "name": "سارة",
  "email": "sara@example.com",
  "role": "user"
}

الاستجابة: 201 Created
Location: /api/users/456
{
  "id": 456,
  "name": "سارة",
  "email": "sara@example.com",
  "role": "user",
  "created_at": "2026-02-14T10:30:00Z"
}
نصيحة: قم دائماً بتضمين رأس Location في استجابات 201 يشير إلى المورد الذي تم إنشاؤه حديثاً. هذا يتبع أفضل ممارسات REST ويساعد العملاء على معرفة مكان العثور على المورد الجديد.

POST للعمليات المعقدة:

يمكن أيضاً استخدام POST للعمليات التي لا تتناسب مع نموذج CRUD القياسي:

// البحث بمعايير معقدة (معقدة جداً لمعاملات استعلام GET)
POST /api/users/search
{
  "filters": {
    "age_range": [18, 65],
    "countries": ["US", "UK", "CA"],
    "interests": ["tech", "sports"]
  }
}

// معالجة إجراء
POST /api/orders/123/ship
{
  "tracking_number": "ABC123",
  "carrier": "FedEx"
}

// عمليات دفعية
POST /api/users/batch-create
{
  "users": [
    {"name": "User1", "email": "user1@example.com"},
    {"name": "User2", "email": "user2@example.com"}
  ]
}

PUT - استبدال المورد بالكامل

يستبدل PUT مورداً كاملاً بالبيانات المقدمة. إذا لم يكن المورد موجوداً، تنشئه بعض واجهات البرمجة (على الرغم من أن هذا اختياري).

الخصائص:

  • غير آمن: يغير حالة الخادم
  • متكافئ: طلبات متطابقة متعددة تنتج نفس النتيجة
  • غير قابل للتخزين المؤقت: افتراضياً
  • له جسم: نعم - تمثيل المورد الكامل

تحديثات الموارد الكاملة:

PUT /api/users/123
Content-Type: application/json

{
  "name": "أحمد محدث",
  "email": "ahmed.new@example.com",
  "role": "admin",
  "bio": "مطور برمجيات"
}

الاستجابة: 200 OK
{
  "id": 123,
  "name": "أحمد محدث",
  "email": "ahmed.new@example.com",
  "role": "admin",
  "bio": "مطور برمجيات",
  "updated_at": "2026-02-14T11:00:00Z"
}
مهم: مع PUT، يجب إرسال جميع حقول المورد. أي حقول لم يتم تضمينها سيتم إزالتها أو تعيينها على null. إذا كنت تريد فقط تحديث حقول محددة، استخدم PATCH بدلاً من ذلك.

PATCH - التحديثات الجزئية

يحدث PATCH حقولاً محددة فقط من المورد دون استبدال المورد بالكامل.

الخصائص:

  • غير آمن: يغير حالة الخادم
  • غير متكافئ: تقنياً (على الرغم من أنه غالباً ما يتم تنفيذه كمتكافئ)
  • غير قابل للتخزين المؤقت: افتراضياً
  • له جسم: نعم - الحقول المراد تحديثها فقط

التحديثات الجزئية:

PATCH /api/users/123
Content-Type: application/json

{
  "email": "ahmed.newest@example.com"
}

الاستجابة: 200 OK
{
  "id": 123,
  "name": "أحمد محدث",  // لم يتغير
  "email": "ahmed.newest@example.com",  // محدث
  "role": "admin",  // لم يتغير
  "bio": "مطور برمجيات",  // لم يتغير
  "updated_at": "2026-02-14T11:15:00Z"
}

PUT مقابل PATCH: متى تستخدم كل منهما

السيناريو استخدم السبب
تحديث ملف المستخدم (جميع الحقول) PUT استبدال المورد بالكامل
تغيير بريد المستخدم الإلكتروني فقط PATCH تحديث حقل واحد
تحديث نموذج تفاصيل المنتج PUT النموذج به جميع الحقول
تبديل حالة المستخدم النشط PATCH قلب منطقي واحد

DELETE - إزالة الموارد

يزيل DELETE مورداً من الخادم بشكل دائم.

الخصائص:

  • غير آمن: يغير حالة الخادم
  • متكافئ: حذف نفس المورد عدة مرات له نفس التأثير
  • غير قابل للتخزين المؤقت: افتراضياً
  • له جسم: عادة لا (على الرغم من أنه مسموح تقنياً)

أنماط الحذف:

// حذف مورد واحد
DELETE /api/users/123

الاستجابة: 204 No Content
// جسم فارغ

// أو مع بيانات تأكيد
الاستجابة: 200 OK
{
  "message": "تم حذف المستخدم بنجاح",
  "deleted_at": "2026-02-14T11:30:00Z"
}

// حذف ناعم (وضع علامة كمحذوف، عدم الإزالة)
DELETE /api/users/123
الاستجابة: 200 OK
{
  "id": 123,
  "deleted": true,
  "deleted_at": "2026-02-14T11:30:00Z"
}

// حذف مورد متداخل
DELETE /api/users/123/posts/456
الاستجابة: 204 No Content
نصيحة: ضع في اعتبارك تنفيذ الحذف الناعم للموارد المهمة. بدلاً من إزالة البيانات من قاعدة البيانات، ضع علامة عليها كمحذوفة مع طابع زمني. هذا يسمح باستعادة البيانات ومسارات التدقيق.

HEAD - الحصول على الرؤوس فقط

HEAD مطابق لـ GET لكنه يعيد الرؤوس فقط بدون جسم الاستجابة. مفيد للتحقق من وجود مورد أو الحصول على البيانات الوصفية.

HEAD /api/users/123

الاستجابة: 200 OK
Content-Type: application/json
Content-Length: 256
Last-Modified: Wed, 14 Feb 2026 11:00:00 GMT
ETag: "abc123"
// لا يوجد جسم مُعاد

// حالات الاستخدام:
// - التحقق من وجود المورد (200 مقابل 404)
// - الحصول على حجم المورد قبل التنزيل
// - التحقق مما إذا تم تعديل المورد (ETag، Last-Modified)
// - التحقق من المصادقة دون تنزيل البيانات

OPTIONS - اكتشاف الأساليب المسموح بها

يعيد OPTIONS أساليب HTTP التي يدعمها الخادم لنقطة نهاية محددة. يُستخدم أيضاً لطلبات CORS preflight.

OPTIONS /api/users/123

الاستجابة: 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Access-Control-Allow-Methods: GET, PUT, PATCH, DELETE
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Headers: Content-Type, Authorization

// مثال CORS preflight
OPTIONS /api/users
Origin: https://frontend.example.com

الاستجابة: 200 OK
Access-Control-Allow-Origin: https://frontend.example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
Access-Control-Max-Age: 86400

رموز حالة HTTP: مرجع كامل

تتواصل رموز الحالة بشأن نتيجة طلب HTTP. اختيار الرمز الصحيح يساعد العملاء على التعامل مع الاستجابات بشكل مناسب.

1xx - استجابات معلوماتية

تشير إلى أنه تم استلام الطلب وجارٍ معالجته. نادراً ما تُستخدم في واجهات برمجة REST.

الرمز المعنى حالة الاستخدام
100 متابعة يجب على العميل المتابعة مع الطلب
101 تبديل البروتوكولات التبديل إلى WebSocket، HTTP/2

2xx - استجابات النجاح

تم استلام الطلب وفهمه وقبوله بنجاح.

الرمز المعنى متى تستخدمه
200 OK GET، PUT، PATCH ناجح
201 Created POST أنشأ مورداً جديداً
202 Accepted تم قبول الطلب، معالجة غير متزامنة
204 No Content DELETE ناجح، لا توجد بيانات للإرجاع
206 Partial Content طلب نطاق (ترقيم، بث)
// 200 OK - نجاح قياسي
GET /api/users/123
الاستجابة: 200 OK
{"id": 123, "name": "أحمد"}

// 201 Created - مورد جديد
POST /api/users
الاستجابة: 201 Created
Location: /api/users/456
{"id": 456, "name": "محمد"}

// 202 Accepted - معالجة غير متزامنة
POST /api/reports/generate
الاستجابة: 202 Accepted
{"job_id": "abc123", "status": "processing"}

// 204 No Content - نجاح، لا بيانات
DELETE /api/users/123
الاستجابة: 204 No Content

3xx - استجابات إعادة التوجيه

هناك حاجة لمزيد من الإجراءات لإكمال الطلب.

الرمز المعنى حالة الاستخدام
301 Moved Permanently المورد دائماً في URL جديد
302 Found إعادة توجيه مؤقتة
304 Not Modified الإصدار المخزن مؤقتاً لا يزال صالحاً
307 Temporary Redirect مؤقت، احتفظ بنفس الأسلوب
308 Permanent Redirect دائم، احتفظ بنفس الأسلوب

4xx - استجابات أخطاء العميل

يحتوي الطلب على بناء جملة خاطئ أو لا يمكن تلبيته. هذه هي الرموز الأكثر أهمية لمطوري واجهات البرمجة.

الرمز المعنى متى تستخدمه
400 Bad Request طلب مشوه، JSON غير صالح
401 Unauthorized مصادقة مفقودة أو غير صالحة
403 Forbidden تم المصادقة ولكن يفتقر إلى الإذن
404 Not Found المورد غير موجود
405 Method Not Allowed أسلوب HTTP غير مدعوم
409 Conflict تعارض الموارد (بريد إلكتروني مكرر)
422 Unprocessable Entity فشل التحقق
429 Too Many Requests تم تجاوز حد المعدل

أمثلة 4xx التفصيلية:

// 400 Bad Request - JSON مشوه
POST /api/users
{name: "محمد"}  // علامات اقتباس مفقودة حول المفتاح

الاستجابة: 400 Bad Request
{
  "error": "بناء جملة JSON غير صالح"
}

// 401 Unauthorized - لا مصادقة
GET /api/users/123

الاستجابة: 401 Unauthorized
{
  "error": "المصادقة مطلوبة",
  "message": "يرجى تقديم رمز وصول صالح"
}

// 403 Forbidden - أذونات غير كافية
DELETE /api/users/456

الاستجابة: 403 Forbidden
{
  "error": "أذونات غير كافية",
  "message": "ليس لديك إذن لحذف المستخدمين"
}

// 404 Not Found - المورد غير موجود
GET /api/users/99999

الاستجابة: 404 Not Found
{
  "error": "المستخدم غير موجود",
  "message": "لا يوجد مستخدم بالمعرف 99999"
}

// 409 Conflict - مورد مكرر
POST /api/users
{"email": "existing@example.com"}

الاستجابة: 409 Conflict
{
  "error": "البريد الإلكتروني موجود بالفعل",
  "message": "يوجد بالفعل مستخدم بهذا البريد الإلكتروني"
}

// 422 Unprocessable Entity - فشل التحقق
POST /api/users
{"name": "أ", "email": "invalid-email"}

الاستجابة: 422 Unprocessable Entity
{
  "error": "فشل التحقق",
  "errors": {
    "name": ["يجب أن يكون الاسم 3 أحرف على الأقل"],
    "email": ["يجب أن يكون البريد الإلكتروني عنوان بريد إلكتروني صالح"]
  }
}

// 429 Too Many Requests - حد المعدل
GET /api/users

الاستجابة: 429 Too Many Requests
Retry-After: 60
{
  "error": "تم تجاوز حد المعدل",
  "message": "حاول مرة أخرى في 60 ثانية"
}

5xx - استجابات أخطاء الخادم

فشل الخادم في تلبية طلب صالح.

الرمز المعنى متى يحدث
500 Internal Server Error خطأ عام في الخادم
502 Bad Gateway استجابة غير صالحة من المنبع
503 Service Unavailable الخادم محمل بشكل زائد أو صيانة
504 Gateway Timeout خادم المنبع لم يستجب
تحذير: أخطاء 5xx تشير إلى مشاكل مع خادمك، وليس العميل. قم دائماً بتسجيل هذه الأخطاء لتصحيح الأخطاء ولا تكشف أبداً تفاصيل الأخطاء الحساسة للعملاء في الإنتاج.
تمرين:

لكل سيناريو، اختر أسلوب HTTP الصحيح ورمز الحالة المتوقع:

  1. المستخدم يحدث صورة ملفه الشخصي: الأسلوب: _____ الحالة: _____
  2. المستخدم يسجل الدخول بالبريد الإلكتروني/كلمة المرور: الأسلوب: _____ الحالة: _____
  3. المستخدم يتحقق مما إذا كان اسم المستخدم متاحاً: الأسلوب: _____ الحالة: _____
  4. المسؤول يحذف حساب مستخدم بشكل ناعم: الأسلوب: _____ الحالة: _____
  5. المستخدم يحاول الوصول إلى لوحة المسؤول بدون إذن: الأسلوب: _____ الحالة: _____

الإجابات: 1) PATCH، 200 2) POST، 200 3) HEAD أو GET، 200/404 4) DELETE، 200 5) GET، 403

النقاط الرئيسية

  • GET للقراءة، وليس للتعديل أبداً - إنه آمن ومتكافئ
  • POST ينشئ الموارد ويعيد 201 مع رأس Location
  • PUT يستبدل الموارد بالكامل، PATCH يحدث حقولاً محددة
  • DELETE يزيل الموارد، ويعيد 204 أو 200
  • استخدم HEAD للتحقق من الوجود دون تنزيل البيانات
  • أرجع دائماً رموز الحالة المناسبة - إنها مهمة للعملاء
  • أخطاء 4xx هي خطأ العميل، أخطاء 5xx هي خطأ الخادم
  • قم بتضمين رسائل خطأ مفيدة في أجسام الاستجابة
معاينة الدرس التالي: الآن بعد أن فهمت أساليب HTTP ورموز الحالة، سنتعلم كيفية تصميم نقاط نهاية واجهة برمجية نظيفة وبديهية مع هيكل URL المناسب واصطلاحات التسمية واستراتيجيات الإصدار.