PATCH
طريقة PATCH PATCH
PATCH تُطبِّق تعديلًا جزئيًا على مورد قائم، عرّفتها RFC 5789 كإضافة منفصلة عن مواصفة HTTP الأساسية.
على عكس PUT، لا يحمل جسم طلب PATCH التمثيل الكامل للمورد، بل مجموعة تغييرات (patch document) تُطبَّق على الحالة الحالية — قد يكون ذلك ببساطة الحقول المراد تعديلها بصيغة JSON، أو بصيغة معيارية أدق مثل JSON Patch (RFC 6902) أو JSON Merge Patch (RFC 7386).
عرّف RFC 5789 هذه الطريقة عام 2010 كامتداد منفصل عن RFC الأساسي لأن HTTP الأصلي لم يتضمّن طريقة للتعديل الجزئي. وخلافًا لـ PUT، فإن PATCH ليست عديمة الأثر التراكمي بالضرورة — قد يعتمد أثرها على الحالة الحالية للمورد (مثل "أضف 1 إلى العدّاد")، لذا لا تفترض ذلك ما لم يوثّقه الخادم صراحةً.
الصياغة
PATCH /resource/:id
Content-Type: application/json
{ ...الحقول المراد تعديلها فقط }📄 مثال
PATCH /api/articles/42 HTTP/1.1
Content-Type: application/json
{ "title": "عنوان جديد فقط" }
// الاستجابة
HTTP/1.1 200 OK
{ "id": 42, "title": "عنوان جديد فقط", "body": "لم يتغيّر" }أهم النقاط
| العنصر | الوظيفة |
|---|---|
| تعديل جزئي | يرسل فقط الحقول المتغيّرة، لا التمثيل الكامل |
| ليست عديمة الأثر التراكمي بالضرورة | بخلاف PUT، أثرها قد يعتمد على الحالة الحالية للمورد |
| لا مواصفة جسم واحدة | قد يكون الجسم JSON عادي أو صيغة معيارية مثل JSON Patch |
💡 نصائح عملية
- وثّق بوضوح في الـ API شكل جسم PATCH المتوقَّع (حقول جزئية أم JSON Patch) لأن المواصفة لا تفرض صيغة واحدة
- أعلن دعم PATCH عبر ترويسة Allow في ردّ OPTIONS
⚠️ أخطاء شائعة
- افتراض أن PATCH عديمة الأثر التراكمي دائمًا مثل PUT — غير مضمون حسب المواصفة
- استخدام PATCH لاستبدال المورد بالكامل — هذا دور PUT، ويجعل السلوك غير متوقَّع للعملاء
خصائص ذات صلة
🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار REST-API الكامل بالعربي.
📚 للتعمق التقني الكامل بالإنجليزية: MDN Web Docs