मैं HTTP पर जाने के लिए एक API डिज़ाइन कर रहा हूँ और अगर HTTP POST कमांड का उपयोग कर रहा हूँ, तो मैं सोच रहा हूँ, लेकिन URL क्वेरी पैरामीटर केवल और बिना किसी अनुरोध के, यह जाने का एक अच्छा तरीका है।
बातें:
- "अच्छा वेब डिज़ाइन" के लिए POST के माध्यम से भेजे जाने वाले गैर-निष्पादक कार्यों की आवश्यकता होती है। यह एक नॉन-इम्पोटेंट एक्शन है।
- URL में अनुरोध पैरामीटर मौजूद होने पर इस ऐप को विकसित करना और डीबग करना आसान है।
- एपीआई व्यापक उपयोग के लिए अभिप्रेत नहीं है।
- ऐसा लगता है कि बिना किसी निकाय के POST का अनुरोध करने से थोड़ा अधिक काम होगा, जैसे
Content-Length: 0हेडर को स्पष्ट रूप से जोड़ा जाना चाहिए। - यह मुझे भी लगता है कि बिना किसी बॉडी वाला POST अधिकांश डेवलपर और HTTP फ्रेमवर्क की अपेक्षाओं के लिए थोड़ा सा काउंटर है।
क्या अनुरोध बॉडी के बजाय URL क्वेरी के माध्यम से POST अनुरोध पर पैरामीटर भेजने के लिए कोई और नुकसान या फायदे हैं?
संपादित करें: इसका कारण यह माना जाता है कि ऑपरेशन बेकार नहीं हैं और पुनर्प्राप्ति के अलावा अन्य दुष्प्रभाव हैं। HTTP युक्ति देखें :
विशेष रूप से, सम्मेलन की स्थापना की गई है कि GET और HEAD विधियां SHOULD में पुनर्प्राप्ति के अलावा अन्य कार्रवाई करने का महत्व नहीं है। इन तरीकों को "सुरक्षित" माना जाना चाहिए। यह उपयोगकर्ता एजेंटों को POST, PUT और DELETE जैसे अन्य तरीकों का प्रतिनिधित्व करने की अनुमति देता है, विशेष तरीके से, ताकि उपयोगकर्ता को इस तथ्य से अवगत कराया जाए कि संभवतः असुरक्षित कार्रवाई का अनुरोध किया जा रहा है।
...
तरीकों में भी "बेकारता" की संपत्ति हो सकती है (एक तरफ त्रुटि या समाप्ति मुद्दों से) एन> 0 के समान प्रभाव के समान अनुरोध एक ही अनुरोध के लिए समान है। GET, HEAD, PUT और DELETE के तरीके इस संपत्ति को साझा करते हैं। इसके अलावा, तरीकों के विकल्प और ट्रेस विकल्प के साइड इफेक्ट्स नहीं हैं, और इसलिए स्वाभाविक रूप से उदासीन हैं।