رقعة (HTTP)

في مجال الحوسبة، تُعدّ طريقة PATCH إحدى طرق طلب HTTP لإجراء تغييرات جزئية على مورد موجود. ^{[ 1 ]} تُقدّم طريقة PATCH كيانًا يحتوي على قائمة بالتغييرات المراد تطبيقها على المورد المطلوب باستخدام مُعرّف الموارد الموحد (URI) الخاص بـ HTTP. ^{[ 1 ]} تُقدّم قائمة التغييرات في شكل مستند PATCH. ^{[ 1 ]} إذا لم يكن المورد المطلوب موجودًا، فقد يقوم الخادم بإنشائه بناءً على نوع وسائط مستند PATCH والأذونات. ^{[ 1 ]} يجب أن تكون التغييرات الموصوفة في مستند PATCH مُحدّدة دلاليًا بشكل جيد، ولكن يمكن أن يكون لها نوع وسائط مختلف عن المورد الذي يتم تعديله. ^{[ 2 ]} يمكن استخدام لغات مثل XML أو JSON لوصف التغييرات في مستند PATCH.

وفقًا للدلالات المحددة في بروتوكول HTTP ، تتطلب طرق GET و PUT و POST استخدام تمثيل كامل للمورد. طريقة PUT، التي تُستخدم لإنشاء الموارد أو استبدالها، هي طريقة متكررة النتائج ، ولا يمكن استخدامها إلا للتحديثات الكاملة. تتطلب نماذج التحرير المستخدمة في تطبيقات Ruby on Rails التقليدية إنشاء موارد جديدة من خلال تطبيق تحديثات جزئية على مورد رئيسي. لهذا السبب، أُضيفت طريقة PATCH إلى بروتوكول HTTP في عام 2010. ^{[ 3 ] [ 4 ]}

يُعدّ بروتوكول HTTP أساسًا لتبادل البيانات على شبكة الإنترنت العالمية . وهو بروتوكول طلب واستجابة يُساعد المستخدمين على التواصل مع الخادم لإجراء عمليات CRUD . يُعرّف بروتوكول HTTP عددًا من طرق الطلب مثل PUT و POST وPATCH لإنشاء الموارد أو تحديثها. ^{[ 5 ]}

يتمثل الفرق الرئيسي بين طريقتي PUT و PATCH في أن طريقة PUT تُرسل نسخة مُعدّلة من المورد المطلوب لتحل محل النسخة الأصلية، بينما تُرسل طريقة PATCH مجموعة من التعليمات لتعديل المورد. إذا كان حجم ملف PATCH أكبر من حجم النسخة الجديدة من المورد المُرسلة بواسطة طريقة PUT ، فإن طريقة PUT هي المُفضّلة. ^{[ 1 ]}

يمكن استخدام طريقة POST لإرسال تحديثات جزئية إلى مورد. الفرق الرئيسي بين طريقتي POST و PATCH هو أن طريقة POST لا تُستخدم إلا إذا كُتبت لدعم التطبيقات أو إذا كانت التطبيقات تدعم دلالاتها، بينما يمكن استخدام طريقة PATCH بشكل عام ولا تتطلب دعمًا من التطبيق. إذا كانت نتيجة استخدام طريقة PATCH غير معروفة، يُفضل استخدام طريقة POST. ^{[ 1 ] [ 6 ]}

تُعدّ طريقة PATCH عملية ذرية . ^{[ 1 ]} إما أن تُطبّق جميع التغييرات المحددة بواسطة طريقة PATCH، أو لا يُطبّق الخادم أيًا منها. ^{[ 1 ]} توجد طرق عديدة للتحقق من نجاح تطبيق التصحيح. على سبيل المثال، يمكن استخدام أداة 'diff' لمقارنة الإصدار الأقدم والإصدار الأحدث من الملف للعثور على الاختلافات بينهما. ^{[ 1 ]}

تُعتبر استجابة PATCH المخزنة مؤقتًا قديمة. ولا يمكن استخدامها إلا لطلبات GET وHEAD التي قد تلي طلب PATCH. ^{[ 1 ]}

لا تنطبق رؤوس الكيانات في مستند PATCH إلا على مستند PATCH نفسه، ولا يمكن تطبيقها على المورد المطلوب. ^{[ 1 ]}

لا يوجد تنسيق قياسي لوثيقة PATCH، ويختلف باختلاف أنواع الموارد. يجب على الخادم التحقق مما إذا كانت وثيقة PATCH المستلمة مناسبة للمورد المطلوب. ^{[ 1 ]}

سيبدو مستند JSON Patch كالتالي

[ { "op" : "add" , "path" : "/count" , "value" : 1 } ]

يمثل "op" العملية التي تُجرى على المورد. ويمثل "path" المورد الذي يتم تعديله. ويمثل "value" القيمة المضافة إلى المورد الحالي. ^{[ 7 ]} قبل تطبيق التغييرات في مستند PATCH، يجب على الخادم التحقق مما إذا كان مستند PATCH المستلم مناسبًا للمورد المطلوب. إذا نجح طلب PATCH، فإنه يُعيد استجابة 204. ^{[ 8 ]}

سيبدو مستند XML PATCH كالتالي

<add sel= "doc/user[@email='xyz@abc.com']" type= "@address" > طريق ABC </add>

يتم تحديد موقع العنصر <user> باستخدام السمة 'email'. وتُضاف سمة جديدة 'address' بقيمة "ABC Road" إلى العنصر <user>. ^{[ 9 ]}

مثال بسيط لطلب PATCH

PATCH/example.txtHTTP/1.1 المضيف: www.example.com نوع المحتوى: تطبيق/مثال شرط المطابقة : "c0b42b66e" طول المحتوى: 120 [ التغييرات : مستند التصحيح الذي يحتوي على جميع التغييرات التي يجب إجراؤها على ملف المثال example.txt]

تم تنفيذ عملية تصحيح ناجحة لملف نصي موجود:

HTTP/1.1204No Content Content-Location: /example.txt ETag : "dd541480"

يشير الرد 204 إلى أن الطلب قد تمت معالجته بنجاح. ^{[ 10 ]}

يستهلك استخدام طريقة PUT نطاقًا تردديًا أكبر مقارنةً بطريقة PATCH عند الحاجة إلى تطبيق تغييرات قليلة على مورد ما. ولكن عند استخدام طريقة PATCH، فإنها تتضمن عادةً جلب المورد من الخادم، ومقارنة الملف الأصلي بالملف الجديد، وإنشاء ملف diff وإرساله. من جانب الخادم، عليه قراءة ملف diff وإجراء التعديلات. وهذا يُضيف عبئًا كبيرًا مقارنةً بطريقة PUT. ^{[ 11 ]} من ناحية أخرى، تتطلب طريقة PUT تنفيذ طلب GET قبل PUT ، ويصعب ضمان عدم تعديل المورد بين طلبي GET و PUT .

لا تعتبر طريقة PATCH "آمنة" بالمعنى المقصود في RFC 2616: فقد تقوم بتعديل الموارد، وليس بالضرورة تلك المذكورة في URI . ^{[ 1 ]}

لا تُعتبر طريقة PATCH طريقةً مُستنسخة . يُمكن جعلها كذلك باستخدام طلب مشروط. ^{[ 1 ]} عندما يُرسل العميل طلبًا مشروطًا إلى مورد، ينجح الطلب فقط إذا لم يتم تحديث المورد منذ آخر مرة وصل إليها العميل. يُساعد هذا أيضًا في منع تلف المورد، حيث لا يُمكن إجراء بعض التحديثات على المورد إلا بدءًا من نقطة أساسية مُحددة. ^{[ 1 ]}

قد يفشل طلب PATCH في حالة حدوث أي من الأخطاء التالية:

يتطلب طلب PATCH استخدام آليات مثل الطلبات المشروطة باستخدام Etags ورأس طلب If-Match لضمان عدم تلف البيانات أثناء عملية التحديث. ^{[ 1 ]} في حالة فشل طلب PATCH أو فشل القناة أو انتهاء المهلة، يمكن للعميل استخدام طلب GET للتحقق من حالة المورد. ^{[ 1 ]} يجب على الخادم ضمان عدم استخدام العملاء الضارين لطريقة PATCH لاستهلاك موارد الخادم بشكل مفرط. ^{[ 1 ]}