التعمق في أساليب HTTP ورموز الحالة
فهم أساليب HTTP بعمق
أساليب 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": "منشور آخر"}
]
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"
}
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"
}
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 | خادم المنبع لم يستجب |
لكل سيناريو، اختر أسلوب HTTP الصحيح ورمز الحالة المتوقع:
- المستخدم يحدث صورة ملفه الشخصي: الأسلوب: _____ الحالة: _____
- المستخدم يسجل الدخول بالبريد الإلكتروني/كلمة المرور: الأسلوب: _____ الحالة: _____
- المستخدم يتحقق مما إذا كان اسم المستخدم متاحاً: الأسلوب: _____ الحالة: _____
- المسؤول يحذف حساب مستخدم بشكل ناعم: الأسلوب: _____ الحالة: _____
- المستخدم يحاول الوصول إلى لوحة المسؤول بدون إذن: الأسلوب: _____ الحالة: _____
الإجابات: 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 هي خطأ الخادم
- قم بتضمين رسائل خطأ مفيدة في أجسام الاستجابة