मैं यूआरआई में इतनी लंबी पैरामीटर स्ट्रिंग देखना नहीं चाहता हूं। तो, विधि जेसन डेटा का उपयोग कर सकते हैं?आराम से एपीआई के लिए, विधि जेसन डेटा का उपयोग कर सकते हैं?
मेरी स्थिति में, मुझे दिए गए पैरामीटर के परिणाम को फ़िल्टर करने की आवश्यकता है। यदि बहुत सारे पैरामीटर हैं, तो लंबाई यूआरआई की सीमा से अधिक हो सकती है। तो, इस समस्या के लिए सबसे अच्छा अभ्यास है?
अपने प्रश्न का उत्तर देने के लिए, हाँ आप जीईटी अनुरोध (यूआरएल-एनकोड प्रदान किए गए) के हिस्से के रूप में यूआरआई में जेएसओएन पास कर सकते हैं। हालांकि, ऐसा करने के आपके कारण पर विचार यूआरआई की लंबाई के कारण है, जेएसओएन का उपयोग करके स्वयं को पराजित करना होगा (आवश्यकतानुसार अधिक वर्ण प्रस्तुत करना)।
मैं सुझाव है कि आप या तो नियमित सीजीआई शैली (param1=val1¶m2=val2) या JSON
इस तरह का अनुरोध HTTP पर आरपीसी है। यह सही नहीं है। –
@ टिचोड्रोमा क्षमा करें, लेकिन यह बस गलत है। यदि वह यूआरआई द्वारा पहचाने गए संसाधन को कॉल करने का निर्देश दे रहा है, तो HTTP प्रोटोकॉल द्वारा परिभाषित विधि के साथ, लक्ष्य संसाधन द्वारा परिभाषित POST semantics के साथ, यह आरपीसी नहीं है। यह आरईएसटी भी नहीं हो सकता है, लेकिन यह आरपीसी नहीं है। यह आरपीसी होगा यदि जेएसओएन पेलोड में पहचानकर्ता शामिल है - यूआरआई के बजाय - और उपयोग करने की विधि - HTTP विधि अर्थशास्त्र पर भरोसा करने के बजाय। –
सिद्धांत रूप में (प्राप्त होने पर अपने एपीआई द्वारा पार्स) में एक पोस्ट अनुरोध के मुख्य भाग में अपने मानकों को भेजने के लिए,, वहाँ कुछ भी नहीं एक अनुरोध भेजने से रोक रहा है GET अनुरोध में शरीर। HTTP प्रोटोकॉल इसे अनुमति देता है, लेकिन इसमें कोई परिभाषित अर्थशास्त्र नहीं है, इसलिए जब आप क्लाइंट GET पेलोड भेजता है तो यह दस्तावेज करने के लिए आप पर निर्भर करता है कि वास्तव में क्या होगा। उदाहरण के लिए, आपको परिभाषित करना होगा कि JSON बॉडी में पैरामीटर क्वेरीस्ट्रिंग पैरामीटर के बराबर हैं या पूरी तरह से कुछ और हैं।
हालांकि, चूंकि कोई स्पष्ट रूप से परिभाषित अर्थशास्त्र नहीं है, इसलिए आपको कोई गारंटी नहीं है कि आपके आवेदन और ग्राहक के बीच कार्यान्वयन इसका सम्मान करेगा। एक सर्वर या प्रॉक्सी पूरे अनुरोध को अस्वीकार कर सकता है, या शरीर को अनदेखा कर सकता है, या कुछ भी। टूटे हुए कार्यान्वयन से निपटने का सबसे अच्छा तरीका यह है कि इसे अपने आवेदन से हटा दिया गया है, इसलिए मैं कहूंगा कि आपके पास दो विकल्प हैं जिन्हें सर्वोत्तम प्रथाओं के रूप में माना जा सकता है।
सरल विकल्प का उपयोग GET के बजाय अन्य उत्तरों द्वारा अनुशंसित किया गया है। चूंकि POST HTTP द्वारा मानकीकृत नहीं है, इसलिए आपको यह दस्तावेज करना होगा कि यह वास्तव में कैसे काम करना चाहिए। यह कम से कम रेस्टस्ट विकल्प है, लेकिन यह ठीक है।
रीस्टफुल विकल्प, जिसे मैं पसंद करता हूं, GET पेलोड को कभी भी छेड़छाड़ नहीं किया जाता है। फिर, अगर किसी के पास टूटा कार्यान्वयन होता है, तो आप X-HTTP-Method-Override के साथ HTTP विधि को ओवरराइड करने की अनुमति देते हैं, जो POST के साथ HTTP विधियों का अनुकरण करने के लिए ग्राहकों के लिए एक लोकप्रिय सम्मेलन है। इसलिए, यदि किसी ग्राहक के पास टूटा कार्यान्वयन होता है, तोके रूप में अनुरोध को X-HTTP-Method-Override: GET विधि भेजकर, और आपके पास एक मिडलवेयर हो सकता है जो आपके एप्लिकेशन कार्यान्वयन से decoupled हो और विधि के अनुसार विधि को फिर से लिखता है। यदि आप एक शुद्धवादी हैं तो यह सबसे अच्छा विकल्प है।
http://stackoverflow.com/a/983458/1907906 के बारे में आप क्या सोचते हैं? –
@ टिचोड्रोमा फील्डिंग एक ही चीज़ कह रही है। एक प्राप्त निकाय के पास HTTP प्रोटोकॉल द्वारा परिभाषित कोई पार्स सेमेन्टिक्स नहीं है, लेकिन इसका मतलब यह नहीं है कि यह HTTP प्रोटोकॉल के रूप में HTTP का उपयोग कर एक आरईएसटी एपीआई में उपयोगी नहीं हो सकता है।इसका मतलब केवल परिवहन प्रोटोकॉल के लिए अप्रासंगिक है और कुछ कार्यान्वयन से इसका सम्मान नहीं किया जा सकता है। –
इस प्रश्न को सप्ताह में कम से कम एक बार SO पर पूछा जाता है। हमेशा दो ही विरोधों को उत्तर के रूप में प्रस्तावित किया जाता है: 1) हां, अनुरोध निकाय के साथ 'प्राप्त करें' पुनः है, 2) नहीं, यह नहीं है। हम सभी बार-बार हमारे विरोधियों को लिखने से कुछ भी नया नहीं सीखते हैं। अभी के लिए मैं इस सवाल को बंद करने के लिए वोट देता हूं क्योंकि यह एक डुप्लिकेट है। इसे भी बंद किया जाना चाहिए क्योंकि उत्तर प्राथमिक रूप से राय आधारित हैं। –