HTTP PUT مقابل PATCH: ما الفرق؟

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

ما هي واجهة البرمجة التطبيقية؟

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

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

نظرة عامة على طرق HTTP؟

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

يتواصل العملاء والخوادم من خلال تبادل رسائل فردية (بدلاً من تيار مستمر من البيانات). تُسمى الرسائل المرسلة من العميل (عادةً متصفح ويب) طلبات، والرسائل المرسلة من الخادم كرد تُسمى ردودًا. HTTP هو بروتوكول قابل للتوسيع تطور بمرور الوقت ويُرسل عبر TCP أو عبر اتصال TCP مشفر بواسطة TLS. نظرًا لقابليته للتوسيع، فإنه يُستخدم ليس فقط لاسترجاع مستندات النصوص التشعبية ولكن أيضًا لاسترجاع الصور ومقاطع الفيديو أو لنشر المحتوى في الخوادم، مثل نتائج نموذج HTML. بالإضافة إلى ذلك، يمكن استخدام HTTP لاسترجاع أجزاء من المستندات لتحديث صفحات الويب عند الطلب.

مقدمة في HTTP PUT

HTTP PUT هو طريقة HTTP تُستخدم لإنشاء مورد جديد أو كتابة تمثيل للمورد المستهدف المعروف للعميل. إنه مشابه لطريقة HTTP POST، والتي تُستخدم لإضافة مورد على الخادم.

ومع ذلك، على عكس POST، فإن PUT هو لا يضر، مما يعني أن استدعاءه مرة واحدة أو عدة مرات متتالية له نفس التأثير (أي لا تأثير جانبي). إذا كان Request-URI يشير إلى مورد موجود بالفعل، يجب اعتبار الكيان المضمن كنسخة معدلة من النسخة الموجودة على الخادم الأصلي.

فهم HTTP PATCH

HTTP PATCH هو طريقة طلب تُستخدم لإجراء تعديلات جزئية على مورد موجود. إنه مشابه لطريقة HTTP PUT، التي تُستخدم لإنشاء مورد جديد أو كتابة تمثيل للمورد المستهدف المعروف للعميل. ومع ذلك، على عكس PUT، يتم استخدام PATCH لتعديل جزء فقط من المورد، بينما يقوم PUT باستبدال المورد بأكمله.

توفر طريقة PATCH كيانًا يتضمن قائمة بالتغييرات التي سيتم تطبيقها على المورد المطلوب باستخدام معرف المورد الموحد (URI) لبروتوكول HTTP. تُعطى قائمة التغييرات في شكل مستند PATCH. تُستخدم طريقة PATCH لتحديث الموارد باستخدام بيانات JSON جزئية.

متى تستخدم HTTP PUT

HTTP PUT تُستخدم لإنشاء مورد جديد أو كتابة تمثيل للمورد المستهدف المعروف للعميل. وهي مناسبة للسيناريوهات التي لديك فيها السيطرة الكاملة على استبدال المورد.

الفارق بين HTTP PUT و HTTP POST هو أن PUT هو لا يضر، مما يعني أن استدعاءه مرة واحدة أو عدة مرات متتالية له نفس التأثير (أي لا تأثير جانبي). إذا كان Request-URI يشير إلى مورد موجود بالفعل، يجب اعتبار الكيان المضمن كنسخة معدلة من النسخة الموجودة على الخادم الأصلي.

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

إليك مثالاً على كيفية استخدام طلب HTTP PUT لتحديث محتوى ملف موجود على الخادم:

PUT /example.html HTTP/1.1
Host: sample.com
Content-Type: text/html
Content-Length: 20

<p>ملف مُحدث</p>

في هذا المثال، يُرسل طلب PUT إلى المورد الموجود في /example.html. رأس Content-Type يحدد أن جسم الطلب في تنسيق HTML. رأس Content-Length يُشير إلى حجم جسم الطلب، والذي في هذه الحالة هو 20 بايت. يحتوي جسم الطلب على المحتوى الجديد للملف، وهو عنصر فقرة HTML بسيط يتضمن النص "ملف مُحدث". إذا كان الملف موجودًا وعالج الخادم الطلب بنجاح، فسوف يستبدل محتوى example.html بالمحتوى الجديد المقدم في جسم الطلب.

متى تستخدم HTTP PATCH

HTTP PATCH يُستخدم لإجراء تعديلات جزئية على مورد موجود. وهو مناسب للسيناريوهات التي تحتاج فيها إلى تحديث جزء فقط من المورد، بينما يُستبدل PUT المورد بأكمله.

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

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

إليك مثالًا على كيفية استخدام طلب HTTP PATCH لتحديث عنوان البريد الإلكتروني لمستخدم في نظام:

PATCH /api/users/123 HTTP/1.1
Host: www.example.com
Content-Type: application/json
If-Match: "e0023aa4e"

{
  "email": "newemail@example.com"
}

في هذا المثال، يُرسل طلب PATCH إلى المورد الموجود في /api/users/123. رأس Content-Type يُحدد أن جسم الطلب في تنسيق JSON. رأس If-Match يُستخدم لضمان أن التحديث يجري تطبيقه فقط إذا كان eTag (معرّف النسخة للمورد) يتطابق مع ذلك المُقدم. يحتوي جسم الطلب على التغيير المراد إجراؤه، والذي في هذه الحالة هو تحديث عنوان البريد الإلكتروني للمستخدم. بعد ذلك، سوف يعالج الخادم هذا الطلب ويطبق التحديث على معلومات المستخدم. إذا كان ذلك ناجحًا، قد يرد الخادم برمز حالة 200 OK وقد يتضمن المورد المحدث في جسم الاستجابة.

الفروق بين HTTP PUT و PATCH

HTTP PUT و HTTP PATCH هما كلاهما طرق HTTP تُستخدم لتعديل الموارد، لكنهما يختلفان في كيفية تحديث المورد.

HTTP PUT تُستخدم لإنشاء مورد جديد أو كتابة تمثيل للمورد المستهدف المعروف للعميل. إنها مناسبة للسيناريوهات التي لديك فيها السيطرة الكاملة على استبدال المورد. إذا كان Request-URI يشير إلى مورد موجود بالفعل، يجب اعتبار الكيان المضمن كنسخة معدلة من النسخة الموجودة على الخادم الأصلي.

HTTP PATCH تُستخدم لإجراء تعديلات جزئية على مورد موجود. إنها مناسبة للسيناريوهات التي تحتاج فيها إلى تحديث جزء فقط من المورد، بينما يُستبدل PUT المورد بأكمله. توفر طريقة PATCH كيانًا يحتوي على قائمة بالتغييرات التي يجب تطبيقها على المورد المطلوب باستخدام معرف المورد الموحد (URI). تُعطى قائمة التغييرات في شكل مستند PATCH.

الفرق الرئيسي بين HTTP PUT و PATCH هو كمية البيانات المرسلة في الطلب. يرسل PUT المورد بالكامل، بينما يرسل PATCH فقط الحقول التي يتم تحديثها. هذا يعني أن طلبات PUT تكون أكثر تكلفة من حيث عرض النطاق الترددي وقوة المعالجة من طلبات PATCH.

مزايا HTTP PUT

HTTP PUT هو طريقة طلب تُستخدم لتحديث أو استبدال مورد موجود على الخادم. تتضمن بعض فوائد استخدام HTTP PUT ما يلي:

• اللا ضرر: HTTP PUT هو طريقة لا تضر، مما يعني أن نفس الطلب يمكن أن يُرسل عدة مرات دون التسبب في أي آثار جانبية.
• الذرة: HTTP PUT هو عملية ذرية، مما يعني أنه إما أن تنجح تمامًا أو تفشل تمامًا. هذا يجعلها مفيدة لتحديث الموارد التي تحتوي على حقول متعددة.
• واجهة موحدة: يتبع HTTP PUT قيود الواجهة الموحدة لخدمات الويب RESTful، مما يجعل من السهل استخدامها وفهمها.
• التخزين المؤقت: يمكن تخزين طلبات HTTP PUT من قبل الوسطاء مثل البروكسيات، مما يساعد في تقليل حركة المرور على الشبكة وتحسين الأداء.

مزايا HTTP PATCH

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

تشمل مزايا استخدام طريقة HTTP PATCH ما يلي:

1. الكفاءة: يسمح PATCH باستخدام أكثر كفاءة لموارد الشبكة عن طريق إرسال التغييرات فقط التي تحتاج إلى تطبيقها، مما يقلل من كمية البيانات المنقولة.
2. التحديثات الجزئية: يتيح لك PATCH تحديث أجزاء محددة من مورد دون التأثير على بقية المورد، مما يوفر تحكمًا دقيقًا على التحديثات.
3. لا يضر: عند استخدامها بشكل صحيح، تكون طلبات PATCH لا تضر، مما يعني أن الطلبات المتطابقة المتعددة ستنتج نفس النتيجة كطلب واحد، مما يقلل من خطر الآثار الجانبية غير المقصودة.

تجعل هذه المزايا HTTP PATCH مفيدة بشكل خاص للحالات المحددة التي تحتاج فيها فقط إلى تحديث مجموعة فرعية من بيانات المورد.

كيفية استخدام Apidog لإرسال طلبات باستخدام HTTP PUT و HTTP PATCH

Apidog هي منصة تعاون متكاملة مصممة لتبسيط عملية العمل مع واجهات البرمجة التطبيقية. تجمع بين ميزات من أدوات مثل Postman وSwagger وMock وJMeter لتوفير حل شامل لوثائق واجهات البرمجة التطبيقية وتصحيح الأخطاء والمزيف والاختبار الآلي.

يتيح لك Apidog إرسال طلبات HTTP لاختبار وإصلاح الأخطاء الخاصة بواجهات البرمجة التطبيقية الخاصة بك دون الحاجة إلى إعادة تعريفها إذا كانت موثقة بالفعل. يتضمن استخدام Apidog لإرسال طلبات PUT و PATCH بضع خطوات.

إرسال طلب HTTP PUT باستخدام Apidog

لإرسال طلب HTTP PUT باستخدام Apidog، يمكنك اتباع هذه الخطوات:

1. افتح Apidog: ابدأ بفتح Apidog وإنشاء طلب جديد.

2. حدد طريقة HTTP: اختر PUT كطريقة HTTP لطلبك.

3. أدخل العنوان URL: أدخل عنوان URL للمورد الذي تريد تحديثه، وأضف أي رؤوس ضرورية، مثل Content-Type أو Authorization وأضف البيانات التي تريد إرسالها في جسم الطلب. يمكنك استخدام معلمة json لإرسال بيانات JSON أو معلمة data لإرسال بيانات مشفرة في النموذج.

4. أرسل الطلب: بمجرد إعداد طلبك، أرسله إلى الخادم.

تحقق من استجابة الخادم لطلب PUT الخاص بك وتعامل معها وفقًا لذلك.

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

إرسال طلب HTTP PATCH باستخدام Apidog

1. افتح Apidog: قم بتشغيل تطبيق Apidog وابدأ بإنشاء طلب جديد داخل التطبيق.

2. حدد طريقة HTTP: اختر PATCH من قائمة طرق HTTP.

3. أدخل العنوان URL: أدخل عنوان نقطة النهاية حيث تريد إرسال طلب PATCH، أضف الرؤوس إذا لزم الأمر وفي جسم الطلب، قم بتضمين البيانات التي ترغب في تحديثها جزئيًا.

نفذ الطلب وانتظر استجابة من الخادم.

قم بتحليل استجابة الخادم للتأكد من نجاح طلب PATCH.

أفضل الممارسات لاستخدام طلبات HTTP PUT و HTTP PATCH

عند العمل مع طرق HTTP مثل PUT و PATCH، من المهم اتباع أفضل الممارسات لضمان أن واجهة البرمجة التطبيقية الخاصة بك موثوقة وكفء وسهلة الاستخدام. فيما يلي بعض أفضل الممارسات لاستخدام طلبات PUT و PATCH:

أفضل الممارسات لاستخدام طلبات HTTP PUT

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

أفضل الممارسات لاستخدام طلبات HTTP PATCH

• استخدم PATCH للتحديثات الجزئية: ينبغي استخدام PATCH للتحديثات الجزئية، أي عندما تحتاج فقط إلى تحديث حقول محددة من المورد.
• تعامل مع عدم الضرر بشكل مناسب: لا يُطلب أن تكون طلبات PATCH لا تضر. إذا كانت تنفيذك لا تضر، يجب أن تتصرف وفقًا لذلك.
• استخدم تنسيق دلتا: أرسل فقط التغييرات (الدلتا) التي تريد تطبيقها على المورد، بدلاً من المورد بالكامل.

أفضل الممارسات العامة لاستخدام HTTP PUT و HTTP PATCH

• تحقق من صحة الإدخال: تحقق دائمًا من صحة بيانات الإدخال لكل من طلبات PUT و PATCH لمنع تحديث البيانات غير الصحيحة.
• استخدم ETags للتحكم في التزامن: تطبيق ETags للتعامل مع التحديثات المتزامنة وتجنب مشكلة "التحديث المفقود".
• ارجع برموز حالة مناسبة: استخدم رموز حالة HTTP بشكل صحيح للإشارة إلى نتيجة الطلب (مثل 200 OK، 204 No Content، 400 Bad Request).
• وثق واجهة البرمجة التطبيقية الخاصة بك: وثق بوضوح السلوك المتوقع لنقاط نهاية PUT و PATCH الخاصة بك، بما في ذلك الحقول المطلوبة وقواعد التحقق.

الخاتمة

في الختام، يُعتبر HTTP PUT و PATCH كلاهما طلبات HTTP مهمة تُستخدم لتحديث الموارد على الخادم. يُفضل استخدام PUT عندما ترغب في استبدال مورد موجود بالكامل ببيانات جديدة، بينما يُفضل استخدام PATCH عندما ترغب في تحديث حقل واحد أو عدد قليل من الحقول في مورد موجود. تمتلك كلا الطلبات مزاياها وعيوبها، والاختيار بينهما يعتمد على الحالة الخاصة.

باستخدام Apidog، لديك القدرة على إرسال طلبات HTTP بسهولة لاختبار وإصلاح الأخطاء في واجهات البرمجة التطبيقية الخاصة بك.