متى تستخدم POST ومتى تستخدم GET؟
https://stackoverflow.com/questions/46585
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
ومما أستطيع أن أجمعه هناك ثلاث فئات:
- لم أستعمل أبدا
GETوالاستخدامPOST - لم أستعمل أبدا
POSTوالاستخدامGET - لا يهم أي واحد تستخدمه.
هل أنا على صواب في افتراض تلك الحالات الثلاث؟إذا كان الأمر كذلك، ما هي بعض الأمثلة من كل حالة؟
المحلول
يستخدم POST للأفعال التدميرية مثل الإنشاء (أنا على دراية بالمفارقة)، والتحرير، والحذف، لأنك لا تستطيع ضرب POST الإجراء في شريط العناوين في متصفحك.يستخدم GET عندما يكون من الآمن السماح لشخص ما بالاتصال بإجراء ما.لذلك عنوان URL مثل:
http://myblog.org/admin/posts/delete/357
يجب أن ينقلك إلى صفحة التأكيد، بدلاً من مجرد حذف العنصر.من الأسهل بكثير تجنب الحوادث بهذه الطريقة.
POST كما أنها أكثر أمانًا من GET, ، لأنك لا تلصق المعلومات في عنوان URL.وذلك باستخدام GET كما method إن نموذج HTML الذي يجمع كلمة مرور أو معلومات حساسة أخرى ليس هو أفضل فكرة.
ملاحظة أخيرة: POST يمكن أن تنقل كمية أكبر من المعلومات من GET.ليس لدى "POST" أي قيود على حجم البيانات المرسلة، بينما يقتصر "GET" على 2048 حرفًا.
نصائح أخرى
باختصار
- يستخدم
GETلsafe andidempotentطلبات - يستخدم
POSTلneither safe nor idempotentطلبات
بالتفصيلهناك مكان مناسب لكل منهما.حتى لو لم تتابع مريح المبادئ، يمكن اكتساب الكثير من التعلم عن REST وكيفية عمل النهج الموجه نحو الموارد.
تطبيق RESTful سوف
use GETsللعمليات التي هي على حد سواءsafe and idempotent.
أ safe العملية هي العملية التي لا not change the data مطلوب.
ان idempotent العملية هي التي ستكون النتيجة be the same بغض النظر عن عدد المرات التي تطلبها.
من المنطقي أنه كما يتم استخدام GETs آمن العمليات تتم تلقائيًا أيضًا عاجز.عادةً ما يتم استخدام GET لاسترداد مورد (سؤال والإجابات المرتبطة به عند تجاوز سعة المكدس على سبيل المثال) أو مجموعة من الموارد.
سيتم استخدام تطبيق RESTful
PUTsللعمليات التيnot safe but idempotent.
أعلم أن السؤال كان حول GET وPOST، ولكنني سأعود إلى POST بعد قليل.
عادةً ما يتم استخدام PUT لتحرير أحد الموارد (تحرير سؤال أو إجابة عند تجاوز سعة المكدس على سبيل المثال).
أ
POSTسيتم استخدامها لأي عملية وهيneither safe or idempotent.
عادةً ما يتم استخدام POST لإنشاء مورد جديد، على سبيل المثال، إنشاء سؤال NEW SO (على الرغم من أنه في بعض التصميمات سيتم استخدام PUT لهذا أيضًا).
إذا قمت بتشغيل POST مرتين فسوف ينتهي بك الأمر إلى إنشاء سؤالين جديدين.
هناك أيضًا عملية حذف، ولكن أعتقد أنه يمكنني ترك ذلك هناك :)
مناقشة
من الناحية العملية، تدعم متصفحات الويب الحديثة عادةً فقط GET وPOST بشكل موثوق (يمكنك إجراء جميع هذه العمليات عبر استدعاءات JavaScript، ولكن فيما يتعلق بإدخال البيانات في النماذج والضغط على إرسال، فلديك عمومًا الخياران).في تطبيق RESTful، غالبًا ما يتم تجاوز POST لتوفير مكالمات PUT وDELETE أيضًا.
ولكن، حتى إذا كنت لا تتبع مبادئ RESTful، فقد يكون من المفيد التفكير في استخدام GET لاسترداد/عرض المعلومات وPOST لإنشاء/تحرير المعلومات.
يجب ألا تستخدم GET مطلقًا في عملية تؤدي إلى تغيير البيانات.إذا قام محرك بحث بالزحف إلى رابط إلى عمليتك الشريرة، أو قام العميل بوضع إشارات مرجعية، فقد يؤدي ذلك إلى حدوث مشكلة كبيرة.
استخدم GET إذا كنت لا تمانع في تكرار الطلب (أي أنه لا يغير الحالة).
استخدم POST إذا أدت العملية إلى تغيير حالة النظام.
نسخة مختصرة
يحصل:يُستخدم عادةً لطلبات البحث المقدمة، أو أي طلب حيث تريد أن يتمكن المستخدم من سحب الصفحة المحددة مرة أخرى.
مزايا الحصول على:
- يمكن وضع إشارة مرجعية على عناوين URL بأمان.
- يمكن إعادة تحميل الصفحات بأمان.
مساوئ الحصول على:
- يتم تمرير المتغيرات عبر عنوان url كأزواج اسم وقيمة.(خطر أمني)
- عدد محدود من المتغيرات التي يمكن تمريرها.(بناء على المتصفح.على سبيل المثال، يقتصر Internet Explorer على 2048 حرفًا.)
بريد:يُستخدم لطلبات الأمان الأعلى حيث يمكن استخدام البيانات لتغيير قاعدة بيانات أو صفحة لا تريد أن يضع شخص ما إشارة مرجعية عليها.
مزايا البريد:
- لا يتم عرض أزواج الاسم والقيمة في عنوان url.(الأمان += 1)
- يمكن تمرير عدد غير محدود من أزواج الاسم والقيمة عبر POST. مرجع.
مساوئ البريد:
- لا يمكن وضع إشارة مرجعية على الصفحة التي تستخدم بيانات POST.(إذا كنت ترغب في ذلك.)
نسخة أطول
مباشرة من بروتوكول نقل النص التشعبي - HTTP/1.1:
9.3 احصل على
تعني طريقة GET استرداد أي معلومات (في شكل كيان) يتم تحديدها بواسطة طلب URI.إذا كان عنوان URI للطلب يشير إلى عملية إنتاج البيانات، فإن البيانات المنتجة هي التي سيتم إرجاعها ككيان في الاستجابة وليس النص المصدر للعملية، ما لم يكن هذا النص هو مخرجات العملية.
تتغير دلالات أسلوب GET إلى "GET مشروط" إذا كانت رسالة الطلب تتضمن حقل رأس If-Modified-Since أو If-Unmodified-Since أو If-Match أو If-None-Match أو If-Range.تطلب طريقة GET الشرطية نقل الكيان فقط في ظل الظروف الموضحة في حقل (حقول) الرأس الشرطي.تهدف طريقة GET الشرطية إلى تقليل الاستخدام غير الضروري للشبكة من خلال السماح بتحديث الكيانات المخزنة مؤقتًا دون الحاجة إلى طلبات متعددة أو نقل البيانات التي يحتفظ بها العميل بالفعل.
تتغير دلالات أسلوب GET إلى "GET جزئي" إذا كانت رسالة الطلب تتضمن حقل رأس النطاق.يطلب GET الجزئي نقل جزء فقط من الكيان، كما هو موضح في القسم 14.35.تهدف طريقة GET الجزئية إلى تقليل الاستخدام غير الضروري للشبكة من خلال السماح بإكمال الكيانات المستردة جزئيًا دون نقل البيانات التي يحتفظ بها العميل بالفعل.
تكون الاستجابة لطلب GET قابلة للتخزين المؤقت فقط إذا كانت تلبي متطلبات التخزين المؤقت لـ HTTP الموضحة في القسم 13.
راجع القسم 15.1.3 للتعرف على الاعتبارات الأمنية عند استخدامها للنماذج.
9.5 مشاركة
يتم استخدام طريقة POST لطلب أن يقبل خادم Origin الكيان المرفق في الطلب باعتباره مرؤوسًا جديدًا للمورد المحدد بواسطة request-uri في خط الطلب.تم تصميم Post للسماح لطريقة موحدة لتغطية الوظائف التالية:
شرح الموارد الموجودة؛
نشر رسالة إلى لوحة إعلانات أو مجموعة أخبار أو قائمة بريدية أو مجموعة مماثلة من المقالات ؛
توفير كتلة من البيانات ، مثل نتيجة إرسال نموذج ، لعملية معالجة البيانات ؛
توسيع قاعدة البيانات من خلال عملية الإلحاق.
يتم تحديد الوظيفة الفعلية التي يتم تنفيذها بواسطة طريقة POST بواسطة الخادم وعادة ما تعتمد على طلب الطلب.إن الكيان المنشور هو تابع لهذا URI بنفس الطريقة التي يكون بها الملف تابعًا لدليل يحتوي عليه ، أو مقال إخباري تابع لمجموعة أخبار يتم نشره إليه ، أو أن السجل تابع لقاعدة بيانات.
قد لا يؤدي الإجراء الذي تنفذه طريقة البريد إلى مورد يمكن تحديده بواسطة URI.في هذه الحالة ، إما 200 (OK) أو 204 (بدون محتوى) هي حالة الاستجابة المناسبة ، اعتمادًا على ما إذا كانت الاستجابة تتضمن كيانًا يصف النتيجة أم لا.
أول شيء مهم هو معنى الحصول على مقابل POST :
- يجب استخدام GET لـ ...يحصل...بعض المعلومات من الخادم،
- بينما يجب استخدام POST لإرسال بعض المعلومات ل الخادم.
وبعد ذلك يمكن الإشارة إلى أمرين:
- باستخدام GET، يمكن للمستخدمين استخدام زر "الرجوع" في متصفحهم، ويمكنهم وضع إشارة مرجعية على الصفحات
- يوجد حد لحجم المعلمات التي يمكنك تمريرها كـ GET (2 كيلو بايت لبعض إصدارات Internet Explorer، إذا لم أكن مخطئًا) ;الحد أكبر بكثير بالنسبة لـ POST، ويعتمد بشكل عام على تكوين الخادم.
على أية حال، لا أعتقد أننا نستطيع "العيش" بدون GET :فكر في عدد عناوين URL التي تستخدمها مع المعلمات في سلسلة الاستعلام، كل يوم - بدون GET، لن تعمل كل هذه ؛-)
بصرف النظر عن اختلاف قيود الطول في العديد من متصفحات الويب، هناك أيضًا اختلاف دلالي.من المفترض أن تكون عمليات GET "آمنة" لأنها عمليات للقراءة فقط ولا تغير حالة الخادم.ستغير عمليات POST عادةً حالتها وستعطي تحذيرات عند إعادة الإرسال.قد تقوم برامج زحف الويب الخاصة بمحركات البحث بإنشاء GETs ولكن لا ينبغي لها أبدًا إنشاء POSTs.
استخدم GET إذا كنت تريد قراءة البيانات دون تغيير الحالة، واستخدم POST إذا كنت تريد تحديث الحالة على الخادم.
قاعدتي العامة هي استخدام Get عندما تقوم بتقديم طلبات إلى الخادم لن تغير الحالة.المشاركات محجوزة للطلبات الموجهة إلى الخادم التي تغير الحالة.
أحد الاختلافات العملية هو أن المتصفحات وخوادم الويب لها حد لعدد الأحرف التي يمكن أن توجد في عنوان URL.يختلف الأمر من تطبيق إلى آخر، ولكن من الممكن بالتأكيد أن تصل إليه إذا كنت قد فعلت ذلك textareaفي النماذج الخاصة بك.
مشكلة أخرى تتعلق بـ GETs - حيث تتم فهرستها بواسطة محركات البحث والأنظمة التلقائية الأخرى.كان لدى Google في السابق منتج يقوم بجلب الروابط مسبقًا على الصفحة التي كنت تشاهدها، لذا سيكون تحميلها أسرع إذا قمت بالنقر فوق تلك الروابط.تسببت في رئيسي الخراب على المواقع التي لديها روابط مثل delete.php?id=1 - فقد الناس مواقعهم بالكامل.
استخدم GET عندما تريد أن يعكس عنوان URL حالة الصفحة.وهذا مفيد لعرض الصفحات التي تم إنشاؤها ديناميكيًا، مثل تلك التي تظهر هنا.يجب استخدام مشاركة في نموذج لإرسال البيانات، كما هو الحال عندما أقوم بالنقر فوق الزر "أرسل إجابتك".كما أنه ينتج عنوان URL أكثر نظافة لأنه لا ينشئ سلسلة معلمات بعد المسار.
ونظرًا لأن ملفات GET هي عناوين URL بحتة، فيمكن تخزينها مؤقتًا بواسطة متصفح الويب وقد يتم استخدامها بشكل أفضل لأشياء مثل الصور التي يتم إنشاؤها باستمرار.(ضبط وقت انتهاء الصلاحية)
مثال واحد من صفحة Gravatar: http://www.gravatar.com/avatar/4c3be63a4c2f539b013787725dfce802?d=monsterid
قد يؤدي GET إلى أداء أفضل قليلاً، حيث تقوم بعض خوادم الويب بكتابة محتويات POST إلى ملف مؤقت قبل استدعاء المعالج.
شيء آخر يجب مراعاته هو الحد الأقصى للحجم.يتم تحديد GETs بحجم عنوان URL، وهو 1024 بايت حسب المعيار، على الرغم من أن المتصفحات قد تدعم المزيد.
يجب أن يستخدم نقل بيانات أكثر من ذلك POST للحصول على توافق أفضل للمتصفح.
حتى أقل من هذا الحد يمثل مشكلة، كما كتب ملصق آخر، أي شيء في عنوان URL يمكن أن ينتهي به الأمر في أجزاء أخرى من واجهة مستخدم المتصفح، مثل السجل.
لا يوجد شيء لا يمكنك القيام به في حد ذاته.النقطة المهمة هي أنك لست كذلك مفترض لتعديل حالة الخادم على HTTP GET.تفترض وكلاء HTTP أنه بما أن HTTP GET لا يعدل الحالة، فإن ما إذا كان المستخدم يستدعي HTTP GET مرة واحدة أو 1000 مرة لن يحدث فرقًا.باستخدام هذه المعلومات، يفترضون أنه من الآمن إرجاع نسخة مخبأة من أول HTTP GET.إذا قمت بخرق مواصفات HTTP فإنك تخاطر بكسر عميل HTTP والوكلاء في البرية.لا تفعل ذلك :)
يتقاطع هذا مع مفهوم REST وكيف كان المقصود من استخدام الويب نوعًا ما.هناك ممتاز تدوين صوتي على راديو هندسة البرمجيات الذي يقدم محادثة متعمقة حول استخدام Get and Post.
يتم استخدام Get لسحب البيانات من الخادم، حيث لا يلزم إجراء التحديث.الفكرة هي أنه يجب أن تكون قادرًا على استخدام نفس طلب GET مرارًا وتكرارًا والحصول على نفس المعلومات.يحتوي عنوان URL على معلومات الحصول على المعلومات في سلسلة الاستعلام، لأنه كان من المفترض أن يتم إرسالها بسهولة إلى الأنظمة الأخرى والأشخاص مثل عنوان حول مكان العثور على شيء ما.
من المفترض أن يتم استخدام المنشور (على الأقل من خلال بنية REST التي يعتمد عليها الويب نوعًا ما) لدفع المعلومات إلى الخادم/إخبار الخادم بتنفيذ إجراء ما.أمثلة مثل:تحديث هذه البيانات، إنشاء هذا السجل.
1.3 قائمة مرجعية سريعة لاختيار HTTP GET أو POST
استخدم GET إذا:
The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
استخدم POST إذا:
The interaction is more like an order, or
The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
The user be held accountable for the results of the interaction.
مصدر.
لا أرى مشكلة في استخدام get بالرغم من ذلك، فأنا أستخدمه لأشياء بسيطة حيث يكون من المنطقي الاحتفاظ بالأشياء في سلسلة الاستعلام.
استخدامه لتحديث الحالة - مثل GET of delete.php?id=5 حذف صفحة أمر محفوف بالمخاطر للغاية.اكتشف الأشخاص ذلك عندما بدأ مسرع الويب من Google في الجلب المسبق لعناوين URL على الصفحات - حيث وصل إلى جميع روابط "الحذف" ومسح بيانات الأشخاص.يمكن أن يحدث نفس الشيء مع عناكب محركات البحث.
يمكن لـ POST نقل البيانات الكبيرة بينما لا يستطيع GET ذلك.
لكن بشكل عام، لا يتعلق الأمر بوجود قصور في GET، بل يتعلق باتفاقية إذا كنت تريد أن يعمل موقع الويب/تطبيق الويب الخاص بك بشكل جيد.
القي نظرة على http://www.w3.org/2001/tag/doc/whenToUseGet.html
من آر إف سي 2616:
9.3 يحصل
تعني طريقة GET استرداد أي المعلومات (في شكل كيان) يتم تحديدها بواسطة طلب uri.إذا كان الطلب-URI يشير إلى عملية إنتاج البيانات ، فستكون البيانات المنتجة هي التي يتم إرجاعها ككيان في الاستجابة وليس النص المصدر للعملية ، ما لم يكن هذا النص هو إخراج العملية.
9.5 بريد
يتم استخدام طريقة POST لطلب أن يقبل خادم Origin الكيان المرفق في الطلب باعتباره مرؤوسًا جديدًا للمورد المحدد بواسطة request-uri في خط الطلب.تم تصميم Post للسماح لطريقة موحدة لتغطية الوظائف التالية:
- شرح الموارد الموجودة؛
- نشر رسالة إلى لوحة إعلانات أو مجموعة أخبار أو قائمة بريدية أو مجموعة مماثلة من المقالات ؛
- توفير كتلة من البيانات ، مثل نتيجة إرسال نموذج ، لعملية معالجة البيانات ؛
- توسيع قاعدة البيانات من خلال عملية الإلحاق.
يتم تحديد الوظيفة الفعلية التي يتم تنفيذها بواسطة طريقة POST بواسطة الخادم وعادة ما تعتمد على طلب الطلب.إن الكيان المنشور هو تابع لهذا URI بنفس الطريقة التي يكون بها الملف تابعًا لدليل يحتوي عليه ، أو مقال إخباري تابع لمجموعة أخبار يتم نشره إليه ، أو أن السجل تابع لقاعدة بيانات.
قد لا يؤدي الإجراء الذي تنفذه طريقة البريد إلى مورد يمكن تحديده بواسطة URI.في هذه الحالة ، إما 200 (OK) أو 204 (بدون محتوى) هي حالة الاستجابة المناسبة ، اعتمادًا على ما إذا كانت الاستجابة تتضمن كيانًا يصف النتيجة أم لا.
أستخدم POST عندما لا أريد أن يرى الأشخاص QueryString أو عندما تصبح QueryString كبيرة.أيضًا، هناك حاجة إلى POST لتحميل الملفات.
لا أرى مشكلة في استخدام GET بالرغم من ذلك، فأنا أستخدمه لأشياء بسيطة حيث يكون من المنطقي الاحتفاظ بالأشياء في QueryString.
سيسمح استخدام GET بالارتباط بصفحة معينة أيضًا حيث لن يعمل POST.
نسخة بسيطة من POST GET PUT DELETE
- استخدم GET - عندما تريد الحصول على أي مورد مثل قائمة البيانات بناءً على أي معرف أو اسم
- استخدم POST - عندما تريد إرسال أي بيانات إلى الخادم.ضع في اعتبارك أن Post هو تشغيل ثقيل للوزن لأنه يجب أن نستخدم PUT بدلاً من النشر داخليًا سيؤدي إلى إنشاء مورد جديد
- استخدم PUT - عندما
كان القصد الأصلي هو استخدام GET لاستعادة البيانات وكان POST أي شيء.القاعدة الأساسية التي أستخدمها هي أنه إذا كنت أرسل أي شيء مرة أخرى إلى الخادم، فإنني أستخدم POST.إذا كنت أتصل فقط بعنوان URL لاستعادة البيانات، فإنني أستخدم GET.
إقرأ ال مقالة عن HTTP في ويكيبيديا.وسوف يشرح ما هو البروتوكول وماذا يفعل:
يحصل
يطلب تمثيلاً للمورد المحدد.لاحظ أنه لا ينبغي استخدام GET للعمليات التي تسبب آثارًا جانبية، مثل استخدامه لاتخاذ إجراءات في تطبيقات الويب.أحد أسباب ذلك هو أنه قد يتم استخدام GET بشكل تعسفي بواسطة الروبوتات أو برامج الزحف، والتي لا ينبغي أن تأخذ في الاعتبار الآثار الجانبية التي يجب أن يسببها الطلب.
و
بريدإرسال البيانات المراد معالجتها (على سبيل المثال، من نموذج HTML) إلى المورد المحدد.يتم تضمين البيانات في نص الطلب.وقد يؤدي ذلك إلى إنشاء مورد جديد أو تحديث الموارد الموجودة أو كليهما.
لدى W3C مستند اسمه معرفات URI وإمكانية العنونة واستخدام HTTP GET وPOST وهذا ما يفسر متى تستخدم ماذا.نقلا عن
1.3 قائمة مرجعية سريعة لاختيار HTTP GET أو POST
- استخدم GET إذا:
- يشبه التفاعل سؤالًا (أي ، إنه عملية آمنة مثل الاستعلام أو عملية القراءة أو البحث).
و
- استخدم POST إذا:
- التفاعل أشبه بالأمر، أو
- يغير التفاعل حالة المورد بطريقة يمكن للمستخدم إدراكها (على سبيل المثال ، الاشتراك في الخدمة) ، أو سال مسؤولية المستخدم عن نتائج التفاعل.
ومع ذلك، قبل اتخاذ القرار النهائي باستخدام HTTP GET أو POST، يرجى أيضًا مراعاة الاعتبارات المتعلقة بالبيانات الحساسة والاعتبارات العملية.
والمثال العملي هو عندما تقوم بإرسال نموذج HTML.يمكنك تحديد إما بريد أو يحصل لعمل النموذج.ستقوم PHP بملء $_GET و $_POST وفقًا لذلك.
في PHP، POST عادةً ما يتم تعيين حد البيانات بواسطة php.ini. GET يقتصر على إعدادات الخادم/المتصفح على ما أعتقد - عادةً ما يكون موجودًا 255 بايت.
من w3schools.com:
ما هو HTTP؟
تم تصميم بروتوكول نقل النص التشعبي (HTTP) لتمكين الاتصالات بين العملاء والخوادم.
يعمل HTTP كبروتوكول استجابة للطلب بين العميل والخادم.
قد يكون متصفح الويب هو العميل ، وقد يكون التطبيق على جهاز كمبيوتر يستضيف موقع ويب هو الخادم.
مثال:يرسل العميل (المتصفح) طلب HTTP إلى الخادم؛ثم يقوم الخادم بإرجاع الرد إلى العميل.تحتوي الاستجابة على معلومات الحالة حول الطلب وقد تحتوي أيضًا على المحتوى المطلوب.
طريقتان لطلب HTTP:الحصول على ونشر
طريقتان شائعتين لاستجابة الطلب بين العميل والخادم هما:الحصول على ونشر.
الحصول على - طلبات البيانات من منشور مورد محدد - يقدم البيانات المراد معالجتها إلى مورد محدد
هنا نميز الاختلافات الرئيسية:
حسنًا، الشيء الرئيسي هو أي شيء تقدمه GET سيتم كشفه عبر عنوان URL.ثانيا، كما يقول Ceejayoz، هناك حد لعدد الأحرف لعنوان URL.
هناك اختلاف آخر وهو أن POST يتطلب عمومًا عمليتين HTTP، بينما يتطلب GET واحدة فقط.
يحرر:يجب أن أوضح - لأنماط البرمجة الشائعة.بشكل عام ، يعد الرد على منشور مع صفحة ويب HTML مباشرة تصميمًا مشكوكًا فيه لمجموعة متنوعة من الأسباب ، أحدها مزعج "يجب إعادة تقديم هذا النموذج ، هل ترغب في القيام بذلك؟" على الضغط على زر العودة.
كما أجاب الآخرون، هناك حد لحجم عنوان url مع get، ويمكن إرسال الملفات مع النشر فقط.
أود أن أضيف هذا واحد يستطيع إضافة أشياء إلى قاعدة بيانات باستخدام الحصول على الإجراءات وتنفيذها باستخدام منشور.عندما يتلقى البرنامج النصي منشورًا أو الحصول على، يمكنه القيام بكل ما يريد المؤلف أن يفعله.أعتقد أن عدم الفهم يأتي من الصياغة التي اختارها الكتاب أو طريقة قراءته.
مؤلف السيناريو يجب استخدم المنشورات لتغيير قاعدة البيانات واستخدم get فقط لاسترجاع المعلومات.
قدمت لغات البرمجة النصية العديد من الوسائل التي يمكن من خلالها الوصول إلى الطلب.على سبيل المثال، PHP يسمح باستخدام $_REQUEST لاسترداد إما مشاركة أو الحصول على.ينبغي للمرء أن يتجنب هذا لصالح أكثر تحديدا $_GET أو $_POST.
في برمجة الويب، هناك مجال أكبر بكثير للتفسير.هناك ما واحد يجب وماذا يستطيع افعل ذلك، ولكن أيهما أفضل غالبًا ما يكون موضع نقاش.ولحسن الحظ، في هذه الحالة، ليس هناك أي غموض.أنت يجب استخدام المشاركات لتغيير البيانات، وأنت يجب استخدم get لاسترداد المعلومات.
جورجابور، mod_rewrite لا يزال يستخدم في كثير من الأحيان GET.إنه يسمح فقط بترجمة عنوان URL أكثر ودية إلى عنوان URL بامتداد GET سلسلة الاستعلام.
لا تحتوي بيانات HTTP Post على حد محدد لكمية البيانات، حيث أن المتصفحات المختلفة لها حدود مختلفة لـ GET.ينص RFC 2068 على ما يلي:
يجب أن تكون الخوادم حذرة بشأن الاعتماد على أطوال URI فوق 255 بايت ، لأن بعض تطبيقات العميل أو الوكيل الأكبر سنا قد لا تدعم هذه الأطوال بشكل صحيح
على وجه التحديد، يجب عليك إنشاء بنيات HTTP الصحيحة لما تُستخدم من أجله.لا ينبغي أن يكون لـ HTTP GET آثار جانبية ويمكن تحديثها وتخزينها بأمان بواسطة وكلاء HTTP، وما إلى ذلك.
يتم استخدام HTTP POST عندما تريد إرسال البيانات مقابل مورد URL.
من الأمثلة النموذجية لاستخدام HTTP GET على البحث، أي.البحث؟ Query = My+Query مثال نموذجي لاستخدام منشور HTTP هو تقديم التعليقات إلى نموذج عبر الإنترنت.
