HTTP बॉडी रिक्वेस्ट बॉडी के साथ

Question

मैं अपने एप्लिकेशन के लिए एक नया Restful webservice विकसित कर रहा हूं।

कुछ संस्थाओं पर GET करते समय, ग्राहक इकाई की सामग्री का अनुरोध कर सकते हैं। यदि वे कुछ मापदंडों को जोड़ना चाहते हैं (उदाहरण के लिए एक सूची को छाँटना) तो वे क्वेरी स्ट्रिंग में इन मापदंडों को जोड़ सकते हैं।

वैकल्पिक रूप से मैं चाहता हूं कि लोग अनुरोध बॉडी में इन मापदंडों को निर्दिष्ट करने में सक्षम हों। HTTP / 1.1 इसे स्पष्ट रूप से मना नहीं करता है। यह उन्हें अधिक जानकारी निर्दिष्ट करने की अनुमति देगा, जटिल XML अनुरोधों को निर्दिष्ट करना आसान बना सकता है।

मेरे सवाल:

• क्या यह एक अच्छा विचार है?
• क्या HTTP क्लाइंट के पास GET अनुरोध के भीतर अनुरोध निकायों का उपयोग करने के मुद्दे हैं?

http://tools.ietf.org/html/rfc2616

Comments

इसका फायदा यह है कि XML या JSON अनुरोध निकायों को आसानी से भेजने की अनुमति है, इसकी लंबाई प्रतिबंध नहीं है और इसे (UTF-8) को एनकोड करना आसान है।

— एवर्ट

यदि आप इसके बाद हैं तो एक सुरक्षित और सुस्पष्ट विधि है जो अनुरोध निकायों को अनुमति देती है, तो आप SEARCH, PROPFIND और REPORT को देखना चाह सकते हैं। बेशक GET का उपयोग नहीं कर रहा है और एक अनुरोध निकाय अधिक या कम कैशिंग को हरा देता है।

— जूलियन रेसके

@fijiaaron: यह 3 साल बाद है, और तब से मैंने वेबसर्विस लिखने का व्यापक अनुभव प्राप्त कर लिया है। यह मूल रूप से मैं पिछले कुछ वर्षों से कर रहा हूं। मैं सुरक्षित रूप से कह सकता हूं, वास्तव में एक GET अनुरोध में एक निकाय जोड़ना बहुत बुरा विचार है। शीर्ष दो उत्तर चट्टान की तरह खड़े हैं।

— Evert

@Ellesedil: सरल शब्दों में: जो भी फायदे POST पर GET का उपयोग करने के लिए मौजूद हैं, वे मौजूद हैं क्योंकि HTTP कैसे डिज़ाइन किया गया है। वे फायदे अब मौजूद नहीं हैं, जब आप इस तरह से मानक का उल्लंघन करते हैं। इसलिए GST + के लिए POST के बजाय एक अनुरोध निकाय का उपयोग करने का केवल एक कारण बचा है: सौंदर्यशास्त्र। सौंदर्यशास्त्र पर मजबूत डिजाइन का त्याग न करें।

— एवर्ट

यह बताने के लिए कि एवर्ट ने क्या कहा: "इसकी लंबाई प्रतिबंध नहीं है"। यदि क्वेरी मापदंडों के साथ आपका GET लंबाई प्रतिबंध (2048 का) तोड़ रहा है, तो क्वेरी स्ट्रिंग जानकारी को एक json ऑब्जेक्ट में रखने के अलावा और क्या विकल्प है, उदाहरण के लिए, अनुरोध के शरीर में।

— कीरन रयान

Answer 1

रॉय फील्डिंग की टिप्पणी एक GET अनुरोध के साथ एक निकाय सहित ।

हाँ। दूसरे शब्दों में, किसी भी HTTP अनुरोध संदेश में एक संदेश निकाय सम्‍मिलित करने की अनुमति है, और इस प्रकार मन में उस संदेश को पार्स करना चाहिए। जीईटी के लिए सर्वर शब्दार्थ, हालांकि, इस तरह प्रतिबंधित हैं कि एक शरीर, यदि कोई हो, तो अनुरोध का कोई अर्थ नहीं है। पार्सिंग की आवश्यकताएं पद्धति शब्दार्थ पर आधारित आवश्यकताओं से अलग होती हैं।

तो, हाँ, आप GET के साथ एक निकाय भेज सकते हैं, और नहीं, ऐसा करना कभी उपयोगी नहीं है।

यह HTTP / 1.1 के स्तरित डिज़ाइन का एक हिस्सा है जो एक बार फिर से विभाजन (प्रगति में काम) होने पर फिर से स्पष्ट हो जाएगा।

.... रॉय

हां, आप GET के साथ एक अनुरोध निकाय भेज सकते हैं लेकिन इसका कोई अर्थ नहीं होना चाहिए। यदि आप इसे सर्वर पर पार्स करके और उसकी सामग्री के आधार पर अपनी प्रतिक्रिया को बदलकर इसका अर्थ देते हैं , तो आप HTTP / 1.1 युक्ति, खंड 4.3 में इस सिफारिश को अनदेखा कर रहे हैं :

[...] यदि अनुरोध पद्धति में निकाय-निकाय के लिए परिभाषित शब्दार्थ शामिल नहीं हैं, तो अनुरोध को संभालते समय संदेश-निकाय SHOULD को अनदेखा किया जाना चाहिए ।

और HTTP / 1.1 युक्ति, खंड 9.3 में GET विधि का वर्णन :

GET विधि का अर्थ है अनुरोध (URI) द्वारा जो भी जानकारी ([...]) की पहचान की जाती है।

जो बताता है कि अनुरोध-निकाय GET अनुरोध में संसाधन की पहचान का हिस्सा नहीं है, केवल अनुरोध URI है।

अद्यतन RFC2616 "HTTP / 1.1 युक्ति" के रूप में संदर्भित अब अप्रचलित है। 2014 में इसे RFCs 7230-7237 द्वारा प्रतिस्थापित किया गया था। "अनुरोध को संभालते समय संदेश-निकाय को अनदेखा किया जाना चाहिए" हटा दिया गया है। यह अब सिर्फ "अनुरोध संदेश फ़्रेमिंग विधि शब्दार्थ से स्वतंत्र है, भले ही विधि किसी संदेश निकाय के लिए किसी भी उपयोग को परिभाषित नहीं करती है" दूसरा उद्धरण "GET विधि का अर्थ है जो भी जानकारी पुनः प्राप्त करें ... अनुरोध-यूआरआई द्वारा पहचानी जाती है" हटाया गया था। - एक टिप्पणी से

Comments

कैशिंग / समीपता वो दो चीजें हैं जिनके टूटने की सबसे अधिक संभावना है, हां। "शब्दार्थ" कहने का एक और तरीका है "जिस तरह से अन्य घटक बनाने वाले लोग अन्य घटकों को संचालित करने की उम्मीद करेंगे"। यदि आप शब्दार्थ का उल्लंघन करते हैं, तो आप उन स्थानों पर चीजों को तोड़ते हुए देख सकते हैं जहां लोगों ने ऐसी चीजें लिखी हैं जिनसे आपको उन शब्दार्थों का सम्मान करने की उम्मीद थी।

— स्टुअर्ट पी। बेंटले

इलास्टिसर्च एक प्रमुख उत्पाद है जो जीईटी में HTTP अनुरोध निकायों का उपयोग करता है। उनके मैनुअल के अनुसार एक HTTP अनुरोध को एक निकाय होने का समर्थन करना चाहिए या नहीं यह अपरिभाषित है। मैं व्यक्तिगत रूप से एक जीईटी अनुरोध निकाय को आबाद करने में सहज नहीं हूं, लेकिन उन्हें एक अलग राय है और उन्हें पता होना चाहिए कि वे क्या कर रहे हैं। elastic.co/guide/en/elasticsearch/guide/current/...

— GordonM

@ जीईएन अनुरोध निकायों को दे रहा है जिसका अर्थ वास्तव में युक्ति का उल्लंघन नहीं है। HTTP / 1.1 निर्दिष्ट करता है कि सर्वर SHOULD शरीर की उपेक्षा करते हैं, लेकिन RFC 2119 निर्दिष्ट करता है कि कार्यान्वयनकर्ताओं को "SHOULD" क्लॉज़ को अनदेखा करने की अनुमति है यदि उनके पास ऐसा करने का अच्छा कारण है। इसके बजाय, एक ग्राहक युक्ति का उल्लंघन करता है यदि यह मान लेता है कि GET शरीर को बदलने से प्रतिक्रिया नहीं बदलेगी।

— एमिल लुंडबर्ग

"HTTP / 1.1 युक्ति" के रूप में संदर्भित RFC2616 अब अप्रचलित है। 2014 में इसे RFCs 7230-7237 द्वारा प्रतिस्थापित किया गया था। " अनुरोध को संभालते समय संदेश-निकाय को अनदेखा किया जाना चाहिए " हटा दिया गया है । यह अब सिर्फ " अनुरोध संदेश फ़्रेमिंग विधि शब्दार्थ से स्वतंत्र है, भले ही विधि किसी संदेश निकाय के लिए किसी भी उपयोग को परिभाषित नहीं करती है " दूसरा उद्धरण " GET विधि का अर्थ है जो भी जानकारी पुनः प्राप्त करें ... अनुरोध-यूआरआई द्वारा पहचानी जाती है " हटा दिया गया था । इसलिए, मैं

— Artem Nakonechny

मुझे पता है कि यह एक पुराना धागा है - मैंने उस पर ठोकर खाई। @Artem Nakonechny तकनीकी रूप से सही है, लेकिन नया चश्मा कहता है "GET अनुरोध संदेश के भीतर एक पेलोड में कोई परिभाषित शब्दार्थ नहीं है, GET अनुरोध पर पेलोड बॉडी भेजने से अनुरोध को अस्वीकार करने के लिए कुछ मौजूदा कार्यान्वयन हो सकते हैं।" तो यह अभी भी एक अच्छा विचार नहीं है अगर बचा जा सकता है।

— फाटक

Answer 2

जब आप ऐसा कर सकते हैं, तो इनफ़ॉफ़र, क्योंकि यह HTTP विनिर्देश द्वारा स्पष्ट रूप से प्रस्तावित नहीं है, मैं इसे केवल इसलिए टालने का सुझाव दूंगा क्योंकि लोग इस तरह से काम करने की उम्मीद नहीं करते हैं। एक HTTP अनुरोध श्रृंखला में कई चरण होते हैं और जब तक वे "ज्यादातर" HTTP कल्पना के अनुरूप होते हैं, केवल एक चीज जो आपको आश्वासन दिया जाता है कि वे परंपरागत रूप से वेब ब्राउज़र द्वारा उपयोग किया जाता है। (मैं पारदर्शी परदे के पीछे, त्वरक, ए / वी टूलकिट, आदि जैसी चीजों के बारे में सोच रहा हूं)

यह रोबस्टनेस सिद्धांत के पीछे की भावना है "मोटे तौर पर आप जो स्वीकार करते हैं उसमें उदार हो, और जो आप भेजते हैं उसमें रूढ़िवादी हैं", आप अच्छे कारण के बिना विनिर्देश की सीमाओं को धक्का नहीं देना चाहते हैं।

हालांकि, यदि आपके पास एक अच्छा कारण है, तो इसके लिए जाएं।

Comments

रोबस्टनेस सिद्धांत त्रुटिपूर्ण है। यदि आप स्वीकार करते हैं कि आप उदार हैं, तो आपको बकवास लगेगा, अगर आपको गोद लेने के संदर्भ में कोई सफलता है, तो सिर्फ इसलिए कि आप बकवास स्वीकार करते हैं। इससे आपको अपने इंटरफ़ेस को विकसित करने में मुश्किल होगी। बस HTML को देखो। यह क्रिया में प्रतिक्षेप सिद्धांत है।

— यूजीन बेरेसोवस्की

मुझे लगता है कि प्रोटोकॉल की दत्तक ग्रहण (और दुरुपयोग) की सफलता और चौड़ाई मजबूती सिद्धांत के मूल्य के लिए बोलती है।

— कास्केय

क्या आपने कभी वास्तविक HTML पार्स करने की कोशिश की है? इसे स्वयं लागू करना संभव नहीं है, इसीलिए लगभग सभी को - जिसमें Google (Chrome) और Apple (Safari) जैसे बड़े खिलाड़ी शामिल हैं, उन्होंने ऐसा नहीं किया, लेकिन मौजूदा कार्यान्वयन पर निर्भर थे (अंत में वे सभी KDE के KHTML पर निर्भर थे)। यह पुन: उपयोग निश्चित रूप से अच्छा है, लेकिन क्या आपने html को एक इन-नेट अनुप्रयोग में प्रदर्शित करने की कोशिश की है? यह एक बुरा सपना है, जैसा कि आपको या तो एक - अप्रबंधित - IE (या समान) घटक को अपने मुद्दों और क्रैश के साथ एम्बेड करना है, या आप उपलब्ध (कोडप्लेक्स पर) प्रबंधित घटक का उपयोग करते हैं जो आपको पाठ का चयन करने की अनुमति भी नहीं देता है।

— यूजीन बेर्सेव्स्की

न केवल HTTP युक्ति शरीर के डेटा को GET अनुरोध के साथ अनुमति देता है, बल्कि यह सामान्य अभ्यास भी है: लोकप्रिय ElasticSearch इंजन का _search API एक JSON बॉडी में संलग्न क्वेरी के साथ GET अनुरोधों की सिफारिश करता है। अपूर्ण HTTP क्लाइंट कार्यान्वयन के लिए रियायत के रूप में, यह यहां POST अनुरोधों को भी अनुमति देता है।

— क्रिश्चियन पिसेट

@ChristianPietsch, आज यह आम बात है। चार साल पहले ऐसा नहीं था। जबकि युक्ति स्पष्ट रूप से एक ग्राहक को अनुरोध (धारा 7) में एक इकाई (MAY) को वैकल्पिक रूप से शामिल करने की अनुमति देती है, MAY का अर्थ RFC2119 में परिभाषित किया गया है और एक (भद्दा) प्रॉक्सी सर्वर GET अनुरोधों में संस्थाओं को अलग करते समय युक्ति का अनुपालन कर सकता है, विशेष रूप से जब तक यह दुर्घटनाग्रस्त नहीं होता है, यह अनुरोध हेडर को अग्रेषित करके 'कम कार्यक्षमता' प्रदान कर सकता है और इसमें शामिल इकाई नहीं है। इसी तरह नियमों के एक मेजबान के बारे में हैं कि कौन से संस्करण बदलते हैं MUST / MAY / SHOULD को तब बनाया जाना चाहिए जब किसी प्रोटोकॉल स्तर के बीच समीप हो।

— कास्की

Answer 3

यदि आप कभी भी कैशिंग का लाभ लेने की कोशिश करते हैं, तो आपको समस्याओं का सामना करना पड़ेगा। प्रॉक्सिस जीईटी निकाय में यह देखने के लिए नहीं जा रहे हैं कि क्या मापदंडों का प्रतिक्रिया पर प्रभाव पड़ता है।

Comments

ETag / अंतिम-संशोधित हेडर फ़ील्ड का उपयोग इस तरह से मदद करता है: जब "सशर्त GET" का उपयोग किया जाता है, तो इस जानकारी पर प्रॉक्सी / कैश कार्य कर सकते हैं।

— jldupont

@jldupont कैश सत्यापनकर्ताओं की उपस्थिति का उपयोग यह जानने के लिए करता है कि क्या बासी प्रतिक्रिया को फिर से मान्य किया जा सकता है, हालांकि, वे प्राथमिक या माध्यमिक कैश कुंजी के हिस्से के रूप में उपयोग नहीं किए जाते हैं।

— डारेल मिलर

आप एक क्वेरी पैरामीटर में शरीर के चेकसम के साथ ठीक कर सकते हैं

— एड्रियन मई

Answer 4

न तो restclient और न ही REST कंसोल इसका समर्थन करता है लेकिन कर्ल करता है।

HTTP विनिर्देशन धारा 4.3 में कहते हैं

यदि अनुरोध विधि (खंड 5.1.1) के विनिर्देश अनुरोध में एक निकाय-निकाय को भेजने की अनुमति नहीं देता है, तो एक संदेश-निकाय अनुरोध में शामिल नहीं होना चाहिए।

खंड 5.1.1 हमें विभिन्न तरीकों के लिए खंड 9.x पर पुनर्निर्देशित करता है। उनमें से कोई भी स्पष्ट रूप से एक संदेश निकाय को शामिल करने पर प्रतिबंध नहीं लगाता है। तथापि...

सेक्शन 5.2 कहता है

इंटरनेट अनुरोध द्वारा पहचाना गया सटीक संसाधन अनुरोध-URI और होस्ट हेडर फ़ील्ड दोनों की जांच करके निर्धारित किया जाता है।

और धारा 9.3 कहता है

GET विधि का अर्थ है अनुरोध-URI द्वारा पहचानी गई किसी भी जानकारी (एक इकाई के रूप में) को पुनः प्राप्त करना।

जो एक साथ सुझाव देते हैं कि जीईटी अनुरोध को संसाधित करते समय, सर्वर को अनुरोध-यूआरआई और होस्ट हेडर फ़ील्ड के अलावा किसी अन्य चीज़ की जांच करने की आवश्यकता नहीं होती है।

सारांश में, HTTP युक्ति आपको GET के साथ एक संदेश-निकाय भेजने से नहीं रोकता है, लेकिन इसमें पर्याप्त अस्पष्टता है कि यह मुझे आश्चर्यचकित नहीं करेगा यदि यह सभी सर्वरों द्वारा समर्थित नहीं था।

Comments

Paw के पास निकायों के साथ GET अनुरोधों का समर्थन करने का विकल्प भी है, लेकिन इसे सेटिंग्स में सक्षम किया जाना चाहिए।

— एस। डैनियल

"GET विधि का अर्थ है, अनुरोध-URI द्वारा पहचानी गई किसी भी जानकारी (एक इकाई के रूप में) को पुनः प्राप्त करना।" फिर, क्या तकनीकी रूप से अवैध / गलत है एक GET समापन बिंदु है जो सभी संस्थाओं को मिलता है? जैसे GET /contacts/100/addressesकि उस व्यक्ति के लिए पते का संग्रह लौटाता है id=100।

— जोश एम।

REST API के परीक्षण के लिए बाकी का आश्वासन दिया गया जावा पुस्तकालय शरीर के साथ GET अनुरोध का समर्थन नहीं करता है। Apache HttpClient या तो इसका समर्थन नहीं करता है।

— पाउलो मर्सन

Django भी एक GET बॉडी को पार्स करने का समर्थन करता है

— ब्रूनो फिंगर

Answer 5

एलिटिक्स खोज एक निकाय के साथ GET अनुरोध स्वीकार करता है। यहां तक ​​कि ऐसा लगता है कि यह पसंदीदा तरीका है: एलेस्टिक्स सर्च

कुछ क्लाइंट लाइब्रेरीज़ (रूबी ड्राइवर की तरह) क्राय कमांड को डेवलपमेंट मोड में लॉग इन कर सकते हैं और इस सिंटैक्स का बड़े पैमाने पर इस्तेमाल कर रहे हैं।

Comments

सोच रहा था कि एलेस्टिक्सखोज इसकी अनुमति क्यों देता है। इसका मतलब यह है कि पेलोड के साथ एक GET अनुरोध करने के लिए सभी दस्तावेजों को गिनने के लिए यह पेलोड सम्‍मिलित करने के curl -XGET 'http://localhost:9200/_count?pretty' -d ' { "query": { "match_all": {} } }' बराबर है source: curl -XGET 'http://localhost:9200/_count?pretty&source=%7B%22query%22%3A%7B%22match_all%22%3A%7B%7D%7D%7D'

— arun

जटिल क्वेरीज़ http हेडर की अधिकतम लंबाई को हिट कर सकती हैं।

— एस। डैनियल

यह इलास्टिक्स खोज दस्तावेज पढ़ रहा था जो मुझे इस सवाल पर ले गया क्योंकि मुझे लगा कि एक शरीर को शामिल करने के लिए इसे बुरा अभ्यास माना जाता है

— पैट्रिकवैलकर

यह एक जटिल प्रश्न होने की भी आवश्यकता नहीं है। यहां तक ​​कि एक साधारण स्क्रॉल बहुत लंबी स्क्रॉल_आईडी (कई शार्क के साथ एक क्लस्टर में) वापस कर सकता है, जो कि वहां जोड़े जाने पर अधिकतम यूआरएल लंबाई को ओवररनिंग कर देगा।

— ब्रेंट हैनिक

एलिस्टिक्सखोज POST का उपयोग करके उसी अनुरोध का समर्थन करता है। उन्होंने केवल GET में एक निकाय को अनुमति देने के लिए चुना क्योंकि उन्हें लगा कि डेटा क्वेरी करने के लिए GET एक POST की तुलना में शब्दार्थ से अधिक सही है। इसका मजेदार यह है कि इस धागे में एलियटेसर्च का इतना उल्लेख किया गया है। मैं अभ्यास का पालन करने के लिए एक उदाहरण (एक लोकप्रिय उत्पाद से यद्यपि) का उपयोग नहीं करूंगा।

— डीएसओ

Answer 6

जो आप प्राप्त करने की कोशिश कर रहे हैं वह लंबे समय से एक बहुत अधिक सामान्य विधि के साथ किया गया है, और एक जो जीईटी के साथ पेलोड का उपयोग करने पर भरोसा नहीं करता है।

आप बस अपने विशिष्ट खोज के मध्य भाग का निर्माण कर सकते हैं, या यदि आप अधिक प्रतिष्ठित होना चाहते हैं, तो OpenSearch जैसी किसी चीज़ का उपयोग करें, और सर्वर द्वारा निर्देश दिए गए URI, अनुरोध / खोज के लिए अनुरोध पोस्ट करें। सर्वर तब खोज परिणाम उत्पन्न कर सकता है या अंतिम URI का निर्माण कर सकता है और 303 का उपयोग करके पुनर्निर्देशित कर सकता है।

यह पारंपरिक पीआरजी विधि का पालन करने का लाभ है, कैश बिचौलियों को परिणाम को कैश करने में मदद करता है, आदि।

उस ने कहा, यूआरआई वैसे भी ASCII नहीं है, और इसलिए एप्लिकेशन / x-www-form-urlencoded और मल्टीपार्ट / फॉर्म-डेटा कुछ भी इनकोड किए जाते हैं। यदि आपका इरादा रेस्टफुल परिदृश्यों का समर्थन करना है तो मैं अभी तक एक और कस्टम जॅसन प्रारूप बनाने के बजाय इसका उपयोग करने की सलाह दूंगा।

Comments

आप बस अपने विशिष्ट खोज का निर्माण कर सकते हैं mediatype क्या आप विस्तृत कर सकते हैं?

— पिओटर डोब्रोगोस्ट सिप

उसके द्वारा मैं कह रहा था कि आप एक मीडिया टाइप बना सकते हैं जिसे एप्लीकेशन / vnd.myCompany.search + json कहा जाता है, जिसमें उस तरह का सर्च टेम्प्लेट होता है, जिसे आप क्लाइंट को इश्यू करना चाहते हैं, और क्लाइंट तब POST के रूप में भेज सकता है। जैसा कि मैंने हाइलाइट किया है, उसके लिए पहले से ही एक मीडिया प्रकार है और इसे OpenSearch कहा जाता है, मौजूदा मीडिया प्रकार का पुन: उपयोग करते हुए कस्टम मार्ग पर चुना जाना चाहिए जब आप अपने परिदृश्य को मौजूदा मानकों के साथ लागू कर सकते हैं।

— सीरियलबेल

यह चतुर है, लेकिन अत्यधिक जटिल और अक्षम है। अब आपको अपने खोज मानदंडों के साथ एक POST भेजना होगा, अपने POST से प्रतिक्रिया के रूप में एक URI प्राप्त करना होगा, फिर खोज मापदंड URI के साथ GET को इसके लिए सर्वर पर GET मानदंड भेजें और परिणाम आपको वापस भेजें। (सिवाय इसके कि एक URI में URI सहित तकनीकी रूप से असंभव है क्योंकि आप कुछ ऐसा नहीं भेज सकते हैं जो 255 वर्णों तक का हो, जो 255 वर्णों से अधिक नहीं हो सकता है - इसलिए आपको आंशिक पहचानकर्ता और अपने सर्वर का उपयोग करना होगा आपके पोस्ट किए गए खोज मानदंडों के लिए URI को कैसे हल किया जाए, यह जानने की जरूरत है।)

— fijiaaron

Answer 7

आप या तो एक निकाय के साथ एक GET भेज सकते हैं या एक POST भेज सकते हैं और RESTish धार्मिकता छोड़ सकते हैं (यह इतना बुरा नहीं है, 5 साल पहले उस विश्वास का केवल एक सदस्य था - ऊपर से जुड़ी उनकी टिप्पणियां)।

न तो महान निर्णय हैं, लेकिन एक GET निकाय भेजने से कुछ ग्राहकों के लिए समस्याओं को रोका जा सकता है - और कुछ सर्वर।

POST करने से कुछ RESTish फ्रेमवर्क में बाधाएं आ सकती हैं।

जूलियन रेस्चके ने "SEARCH" जैसे एक गैर-मानक HTTP हेडर का उपयोग करने का सुझाव दिया, जो एक सुरुचिपूर्ण समाधान हो सकता है, सिवाय इसके कि इसके समर्थन की संभावना भी कम है।

यह उन ग्राहकों को सूचीबद्ध करने के लिए सबसे अधिक उत्पादक हो सकता है जो उपरोक्त प्रत्येक को नहीं कर सकते हैं।

वे ग्राहक जो शरीर के साथ GET नहीं भेज सकते (जो मुझे पता है):

• XmlHTTPRequest फ़िडलर

ग्राहक जो शरीर के साथ GET भेज सकते हैं:

• अधिकांश ब्राउज़र

सर्वर और लाइब्रेरी जो GET से निकाय प्राप्त कर सकते हैं:

• अमरीका की एक मूल जनजाति
• पीएचपी

सर्वर (और समीपता) जो GET से निकाय छीनते हैं:

• ?

Comments

स्क्वीड 3.1.6 स्ट्रिप्स भी प्राप्त करता है जब कंटेंट-लेंथ 0 है या सेट नहीं है, और अन्यथा एक HTTP 411 लेंथ को वापस भेज देता है, भले ही लंबाई सेट होने के बावजूद आवश्यक हो

— rkok

फिडलर करेगा, लेकिन यह आपको चेतावनी देता है।

— toddmo

क्या आप कह रहे हैं कि एक SEARCHविधि संभवतः रास्ते से टूट जाएगी? यदि परदे के पीछे कोई विधि समझ में नहीं आती है, तो उनसे अपेक्षा की जाती है कि वे इस तरह से गुजरें, इसलिए मुझे यकीन नहीं है कि आपको लगता है कि यह कुछ भी तोड़ देगा ...

— एलेक्सिस विलके

Answer 8

मैंने इस सवाल को IETF HTTP WG पर रखा। रॉय फील्डिंग (1998 में http / 1.1 दस्तावेज़ के लेखक) की टिप्पणी थी

"... एक कार्यान्वयन पार्स के अलावा कुछ भी करने और उस शरीर को त्यागने के लिए टूट जाएगा यदि प्राप्त हुआ"

RFC 7213 (HTTPbis) कहता है:

"GET अनुरोध संदेश के भीतर एक पेलोड कोई परिभाषित शब्दार्थ नहीं है;"

अब यह स्पष्ट प्रतीत होता है कि आशय यह था कि जीईटी अनुरोध निकायों पर अर्थ का अर्थ निषिद्ध है, जिसका अर्थ है कि परिणाम को प्रभावित करने के लिए अनुरोध निकाय का उपयोग नहीं किया जा सकता है।

यदि आप GET पर एक निकाय शामिल करते हैं, तो निश्चित रूप से आपके अनुरोध को विभिन्न तरीकों से तोड़ दिया जाएगा ।

तो संक्षेप में, यह मत करो।

Answer 9

कौन सा सर्वर इसे अनदेखा करेगा? - फिजियारोन 30 अगस्त को 21:27 बजे

उदाहरण के लिए Google इसे अनदेखा करने से भी बदतर है, यह इसे एक त्रुटि मानेगा !

अपने आप को एक सरल नेटकैट के साथ आज़माएं:

$ netcat www.google.com 80
GET / HTTP/1.1
Host: www.google.com
Content-length: 6

1234

(CR-LF द्वारा 1234 सामग्री का अनुसरण किया जाता है, इसलिए यह कुल 6 बाइट्स है)

और आपको मिलेगा:

HTTP/1.1 400 Bad Request
Server: GFE/2.0
(....)
Error 400 (Bad Request)
400. That’s an error.
Your client has issued a malformed or illegal request. That’s all we know.

आपको Bing, Apple, आदि से 400 खराब अनुरोध भी मिलते हैं ... जो कि AkamaiGhost द्वारा दिए जाते हैं।

इसलिए मैं एक निकाय इकाई के साथ GET अनुरोधों का उपयोग करने की सलाह नहीं दूंगा।

Comments

यह उदाहरण व्यर्थ है क्योंकि आमतौर पर जब लोग GETअनुरोधों के लिए शरीर को जोड़ने जा रहे हैं , यह इसलिए है क्योंकि उनका स्वयं का कस्टम सर्वर इसे संभालने में सक्षम है। इस प्रकार सवाल यह है कि क्या अन्य "चलती भागों" (ब्राउज़र, कैश, आदि) ठीक से काम करेंगे।

— 1

यह एक बुरा अनुरोध है क्योंकि GET उस विशेष समापन बिंदु पर आपके पेलोड की उम्मीद (या समझदार) नहीं है - इसका GETसामान्य मामले में उपयोग से कोई लेना-देना नहीं है । एक यादृच्छिक पेलोड एक POSTबस को आसानी से तोड़ सकता है, और उसी को वापस कर सकता है 400 Bad Request, अगर सामग्री एक प्रारूप में नहीं थी जो विशिष्ट अनुरोध के संदर्भ में समझ में आता है।

— नोबार

और केवल उस समापन बिंदु पर ही नहीं , बल्कि उस विशिष्ट URL पर ।

— लॉरेंस डॉल

यह अप्रासंगिक है क्योंकि यह उस URL पर केवल Google का सर्वर कार्यान्वयन है। तो यह सवाल का कोई मतलब नहीं है

— जोएल डकवर्थ

मेरे लिए यह उपयोगी था, क्योंकि मैं एक रिक्वेस्ट + बॉडी के साथ फायरबेस फंक्शन्स का उपयोग करने की कोशिश कर रहा था, और यह त्रुटि बहुत ही गूढ़ और समझने में कठिन हो सकती है।

— स्क्रिमाउ

Answer 10

से RFC 2616, खंड 4.3 , "संदेश का मुख्य भाग":

एक सर्वर किसी भी अनुरोध पर संदेश-निकाय को पढ़ता और अग्रेषित करता है; यदि अनुरोध विधि में निकाय-निकाय के लिए परिभाषित शब्दार्थ शामिल नहीं हैं, तो अनुरोध को संभालते समय संदेश-निकाय SHOULD को अनदेखा किया जाना चाहिए।

यही है, सर्वर को हमेशा नेटवर्क से किसी भी प्रदान किए गए अनुरोध शरीर को पढ़ना चाहिए (सामग्री-लंबाई की जांच करें या एक कटा हुआ शरीर, आदि पढ़ें)। इसके अलावा, परदे के पीछे किसी भी ऐसे अनुरोध निकाय को प्राप्त करना चाहिए जो उन्हें प्राप्त हो। फिर, यदि RFC दी गई विधि के लिए शरीर के लिए शब्दार्थ को परिभाषित करता है, तो सर्वर वास्तव में प्रतिक्रिया उत्पन्न करने में अनुरोध निकाय का उपयोग कर सकता है। हालांकि, अगर RFC शरीर के लिए शब्दार्थ को परिभाषित नहीं करता है, तो सर्वर को इसे अनदेखा करना चाहिए।

यह ऊपर क्षेत्ररक्षण के उद्धरण के अनुरूप है।

खंड 9.3 , "GET", GET विधि के शब्दार्थ का वर्णन करता है, और अनुरोध निकायों का उल्लेख नहीं करता है। इसलिए, एक सर्वर को GET अनुरोध पर प्राप्त किसी भी अनुरोध निकाय को अनदेखा करना चाहिए।

Comments

धारा 9.5 , "POST", अनुरोध निकायों का भी उल्लेख नहीं करता है, इसलिए यह तर्क त्रुटिपूर्ण है।

— कारलुवा

@CarLuva POST अनुभाग कहता है "POST विधि का उपयोग यह अनुरोध करने के लिए किया जाता है कि मूल सर्वर संलग्न इकाई को स्वीकार करता है ..." निकाय निकाय अनुभाग कहता है "इकाई-निकाय संदेश-निकाय से प्राप्त होता है ..." इसलिए, POST अनुभाग संदेश निकाय का उल्लेख करता है, हालांकि परोक्ष रूप से उस निकाय का संदर्भ देकर जो POST अनुरोध के संदेश निकाय द्वारा किया जाता है।

— frederickf

Answer 11

XMLHttpRequest के अनुसार, यह मान्य नहीं है। से मानक :

4.5.6 send()विधि

client . send([body = null])

अनुरोध शुरू करता है। वैकल्पिक तर्क अनुरोध निकाय प्रदान करता है। यदि अनुरोध विधि GETया है तो तर्क की अनदेखी की जाती है HEAD।

InvalidStateErrorयदि राज्य नहीं खोला गया है या send()ध्वज सेट है , तो एक अपवाद फेंकता है।

विधि निम्न चरणों का चलाना चाहिए:send(body)

1. यदि राज्य नहीं खोला गया है , तो एक InvalidStateErrorअपवाद फेंक दें ।
2. यदि send()झंडा सेट है, तो एक InvalidStateErrorअपवाद फेंक दें ।
3. यदि अनुरोध विधि है GETया HEAD, शरीर को अशक्त करने के लिए सेट करें ।
4. यदि शरीर अशक्त है, तो अगले चरण पर जाएं।

हालाँकि, मुझे नहीं लगता कि यह होना चाहिए क्योंकि GET अनुरोध के लिए बड़ी सामग्री की आवश्यकता हो सकती है।

इसलिए, यदि आप किसी ब्राउज़र के XMLHttpRequest पर भरोसा करते हैं, तो संभावना है कि यह काम नहीं करेगा।

Comments

इस तथ्य के कारण डाउनवोट किया गया कि XMLHttpRequest एक कार्यान्वयन है। इसे लागू करने वाले वास्तविक विनिर्देश को प्रतिबिंबित नहीं किया जा सकता है।

— जूल

ऊपर नीचे करना गलत है, अगर कुछ कार्यान्वयन एक निकाय को जीईटी के साथ भेजने का समर्थन नहीं करते हैं, तो यह ऐसा करने का एक कारण हो सकता है, भले ही विनिर्देश के बावजूद। मैं वास्तव में एक क्रॉस-प्लेटफ़ॉर्म उत्पाद पर इस सटीक समस्या में भाग गया, जिस पर मैं काम कर रहा हूं - केवल XMLHttpRequest का उपयोग करने वाला प्लेटफ़ॉर्म, जो भेजने में विफल रहा।

— pjcard

Answer 12

यदि आप वास्तव में वेब एप्लिकेशन को कैशबल JSON / XML बॉडी भेजना चाहते हैं, तो अपना डेटा डालने के लिए एकमात्र उचित स्थान RFC4648 के साथ एन्कोडेड क्वेरी स्ट्रिंग है : बेस 64 URL और फाइलनाम सुरक्षित वर्णमाला के साथ एन्कोडिंग । बेशक आप सिर्फ JSON का उपयोग कर सकते हैं और URL को URL के मान में डाल सकते हैं, लेकिन Base64 छोटे परिणाम देता है। ध्यान रखें कि URL आकार प्रतिबंध हैं, देखें कि विभिन्न ब्राउज़रों में URL की अधिकतम लंबाई क्या है? ।

आप सोच सकते हैं कि =URL के परम मान के लिए बेस 64 का पेडिंग कैरेक्टर खराब हो सकता है, हालाँकि ऐसा नहीं लगता - इस चर्चा को देखें: http://mail.python.org/pipermail/python-bugs-list/2007-Febdays/019195.html । हालाँकि आपको बिना परम डेटा के एन्कोडेड डेटा नहीं डालना चाहिए क्योंकि पैडिंग के साथ एन्कोडेड स्ट्रिंग को खाली मान के साथ परम की के रूप में व्याख्या की जाएगी। मैं कुछ इस तरह का उपयोग करेंगे ?_b64=<encodeddata>।

Comments

मुझे लगता है कि यह एक बहुत बुरा विचार है :) लेकिन अगर मुझे ऐसा कुछ करना था, तो मैं इसके बजाय एक कस्टम HTTP हेडर का उपयोग करूंगा (और सुनिश्चित करें कि मैं हमेशा वैरी भेजूं: प्रतिक्रिया में)।

— Evert

खराब या नहीं, लेकिन संभव है :) हेडर में डेटा के साथ डेटा आकार के साथ समान समस्या है, stackoverflow.com/questions/686217/… देखें । हालांकि Varyहेडर का उल्लेख करने के लिए धन्यवाद , मुझे इसकी वास्तविक क्षमता के बारे में पता नहीं था।

— gertas

Answer 13

मैं यह सलाह नहीं दूंगा, यह मानक प्रथाओं के खिलाफ जाता है, और बदले में इतना नहीं देता है। आप सामग्री के लिए शरीर रखना चाहते हैं, विकल्प नहीं।

Answer 14

गैर-अनुरूपण आधार 64 एनकोडिंग हेडर के बारे में क्या? "SOMETHINGAPP-पैरामीटर: sdfSD45fdg45 / के रूप में"

लंबाई प्रतिबंध एच.एम. क्या आप अपने POST हैंडलिंग को अर्थों के बीच अंतर नहीं कर सकते हैं? यदि आप छँटाई जैसे साधारण पैरामीटर चाहते हैं, तो मुझे नहीं लगता कि यह समस्या क्यों होगी। मुझे लगता है कि यह निश्चित है कि आप किस बारे में चिंतित हैं।

Comments

आप x-उपसर्ग के साथ कोई भी पैरामीटर भेज सकते हैं , हेडर की लंबाई पर कोई सीमा पूरी तरह से एक सर्वर मनमानी सीमा होगी।

— क्रिस मैरिसिक

Answer 15

मुझे लगता है कि प्रोटोकॉल OOP का समर्थन नहीं करता है और Getविधि सबूत है कि मैं परेशान हूँ । एक समाधान के रूप में, आप अपने डीटीओ को JSON में अनुक्रमित कर सकते हैं और फिर एक क्वेरी स्ट्रिंग बना सकते हैं। सर्वर की ओर से आप डीटीओ को क्वेरी स्ट्रिंग को डिस्क्राइब करने में सक्षम होंगे।

पर एक नज़र रखना:

• ServiceStack में संदेश-आधारित डिज़ाइन
• WCF के साथ प्रतिष्ठित संदेश आधारित वेब सेवाओं का निर्माण

संदेश आधारित दृष्टिकोण आपको विधि प्रतिबंध को हल करने में मदद कर सकता है। आप किसी भी डीटीओ को अनुरोध निकाय के साथ भेजने में सक्षम होंगे

नालिबुर वेब सेवा ढांचा कार्यक्षमता प्रदान करता है जिसका आप उपयोग कर सकते हैं

var client = new JsonServiceClient(Settings.Default.ServiceAddress);
var request = new GetClientRequest
    {
        Id = new Guid("2217239b0e-b35b-4d32-95c7-5db43e2bd573")
    };
var response = client.Get<GetClientRequest, ClientResponse>(request);

as you can see, the GetClientRequest was encoded to the following query string

http://localhost/clients/GetWithResponse?type=GetClientRequest&data=%7B%22Id%22:%2217239b0e-b35b-4d32-95c7-5db43e2bd573%22%7D

Comments

आपको बस POST का उपयोग करना चाहिए। यदि url में कोई विधि नाम है, तो आप मूल रेस्ट डिज़ाइन का उल्लंघन कर रहे हैं। यह RPC है, POST का उपयोग करें।

— एवर्ट

मुझे नहीं लगता कि यह कोई बड़ी बात है, हमें Restful url (यानी ऑर्डर / 1) के साथ विकास के दौरान अधिक समस्याएं हैं। मेरे लिए, गेट मेथड में कुछ गड़बड़ है, यह OOP के साथ असंगत है। और जो परवाह करते हैं कि url कैसा दिखता है :) लेकिन संदेश आधारित दृष्टिकोण के साथ हम स्थिर दूरस्थ इंटरफ़ेस बना सकते हैं और यह वास्तव में महत्वपूर्ण है। PS यह RPC नहीं है, यह संदेश आधारित है

— GSerjo

मुझे लगता है कि आप REST का पूरा बिंदु याद कर रहे हैं। जब आप कहते हैं, कौन परवाह करता है कि url कैसा दिखता है, अच्छी तरह से REST परवाह करता है, बहुत कुछ। और OEST OOP के साथ संगत क्यों होगा?

— shmish111 13

नहीं, मैंने नहीं देखा कि मैं अभी थोड़ा आगे

— हूं

Answer 16

उदाहरण के लिए, यह कर्ल, अपाचे और पीएचपी के साथ काम करता है।

PHP फ़ाइल:

<?php
echo $_SERVER['REQUEST_METHOD'] . PHP_EOL;
echo file_get_contents('php://input') . PHP_EOL;

कंसोल कमांड:

$ curl -X GET -H "Content-Type: application/json" -d '{"the": "body"}' 'http://localhost/test/get.php'

आउटपुट:

GET
{"the": "body"}

Comments

मजेदार प्रयोग! पीएचपी केवल में पढ़ा जाएगा $_POSTजब शरीर एक पोस्ट अनुरोध और साथ भेजा जाता है application/x-www-form-urlencoded। इसका मतलब है कि GETअनुरोध में शरीर की अनदेखी की जाती है । इस मामले में: $_GETऔर $_POSTइस बिंदु पर वैसे भी बहुत भ्रामक हैं। इसलिए बेहतर उपयोग करेंphp://input

— मार्टिन मुजतको

Answer 17

IMHO आप सिर्फ JSONएन्कोडेड (यानी encodeURIComponent) में भेज सकते हैं URL, इस तरह से आप HTTPचश्मे का उल्लंघन नहीं करते हैं और JSONसर्वर पर पहुंच जाते हैं ।

Comments

हाँ, लेकिन प्रमुख मुद्दा लंबाई सीमा थी, हम इससे कैसे निपटते हैं?

— सेबास

Answer 18

आपके पास विकल्पों की एक सूची है जो GET वाले अनुरोध निकाय का उपयोग करने से कहीं बेहतर है।

मान लें कि आपके पास प्रत्येक श्रेणी के लिए श्रेणियां और आइटम हैं। दोनों को इस उदाहरण के लिए एक आईडी ("कैटिड" / "आइटमिड") द्वारा पहचाना जाना चाहिए। आप एक विशिष्ट "क्रम" में दूसरे पैरामीटर "सॉर्टबी" के अनुसार क्रमबद्ध करना चाहते हैं। आप "सॉर्टबी" और "ऑर्डर" के लिए पैरामीटर पास करना चाहते हैं:

आप ऐसा कर सकते हैं:

1. क्वेरी स्ट्रिंग का उपयोग करें, जैसे example.com/category/{catid}/item/{itemid}?sortby=itemname&order=asc
2. रास्तों के लिए mod_rewrite (या समान) का उपयोग करें: example.com/category/{catid}/item/{itemid}/{sortby}/{order}
3. व्यक्तिगत HTTP हेडर का उपयोग करें जिसे आप अनुरोध के साथ पास करते हैं
4. एक संसाधन को पुनः प्राप्त करने के लिए एक अलग विधि, जैसे POST का उपयोग करें।

सभी के पास अपने डाउनसाइड हैं, लेकिन एक शरीर के साथ जीईटी का उपयोग करने से कहीं बेहतर है।

Answer 19

यहां तक ​​कि अगर कोई लोकप्रिय टूल इस का उपयोग करता है, जैसा कि इस पृष्ठ पर अक्सर उद्धृत किया गया है, तो मुझे लगता है कि यह अभी भी काफी बुरा विचार है, बहुत विदेशी होने के बावजूद, कल्पना द्वारा मना नहीं किया गया है।

कई मध्यवर्ती इन्फ्रास्ट्रक्चर इस तरह के अनुरोधों को अस्वीकार कर सकते हैं।

उदाहरण रखकर, अपनी वेब साइट के सामने उपलब्ध CDN के कुछ का उपयोग कर इस तरह के बारे में भूल एक :

यदि एक दर्शक GETअनुरोध में एक निकाय शामिल है, तो CloudFront एक HTTP स्थिति कोड 403 (निषिद्ध) को दर्शक को देता है।

और हाँ, आपके ग्राहक पुस्तकालय भी इस तरह के अनुरोधों का समर्थन नहीं कर सकते हैं, जैसा कि इस टिप्पणी में बताया गया है ।

Answer 20

मैं अपने क्लाइंट प्रोग्राम में स्प्रिंग फ्रेमवर्क के रेस्टेमप्लेट का उपयोग कर रहा हूं और सर्वर-साइड पर, मैंने एक Json बॉडी के साथ GET अनुरोध को परिभाषित किया है। मेरा प्राथमिक उद्देश्य आपके जैसा ही है: जब अनुरोध में कई पैरामीटर होते हैं, तो उन्हें लंबे समय तक यूआरआई स्ट्रिंग में डालने की तुलना में शरीर में डालने से तनाव महसूस होता है। हाँ?

लेकिन, दुख की बात है कि यह काम नहीं कर रहा है! सर्वर-साइड ने निम्न अपवाद को फेंक दिया:

org.springframework.http.converter.HttpMessageNotReadableException: आवश्यक अनुरोध बॉडी गायब है ...

लेकिन मुझे पूरा यकीन है कि मेरे ग्राहक कोड द्वारा संदेश बॉडी को सही तरीके से प्रदान किया गया है, इसलिए क्या गलत है?

मैंने RestTemplate.exchange () विधि में पता लगाया और निम्नलिखित पाया:

// SimpleClientHttpRequestFactory.class
public class SimpleClientHttpRequestFactory implements ClientHttpRequestFactory, AsyncClientHttpRequestFactory {
    ...
    protected void prepareConnection(HttpURLConnection connection, String httpMethod) throws IOException {
        ...
        if (!"POST".equals(httpMethod) && !"PUT".equals(httpMethod) && !"PATCH".equals(httpMethod) && !"DELETE".equals(httpMethod)) {
            connection.setDoOutput(false);
        } else {
            connection.setDoOutput(true);
        }
        ...
    }
}

// SimpleBufferingClientHttpRequest.class
final class SimpleBufferingClientHttpRequest extends AbstractBufferingClientHttpRequest {
    ...
    protected ClientHttpResponse executeInternal(HttpHeaders headers, byte[] bufferedOutput) throws IOException {
        ...
        if (this.connection.getDoOutput() && this.outputStreaming) {
            this.connection.setFixedLengthStreamingMode(bufferedOutput.length);
        }

        this.connection.connect();
        if (this.connection.getDoOutput()) {
            FileCopyUtils.copy(bufferedOutput, this.connection.getOutputStream());
        } else {
            this.connection.getResponseCode();
        }
        ...
    }
}

कृपया ध्यान दें कि निष्पादनयोग्य () विधि में, इनपुट तर्क 'बफ़रड ऑउटपुट' में मेरे कोड द्वारा प्रदान संदेश निकाय है। मैंने इसे डिबगर के माध्यम से देखा।

हालाँकि, तैयार होने के कारण (), getDoOutput () निष्पादित में (हमेशा) झूठा लौटता है, जो बदले में, बफ़रऑउटपुट को पूरी तरह से अनदेखा कर देता है! इसे आउटपुट स्ट्रीम में कॉपी नहीं किया गया है।

नतीजतन, मेरे सर्वर प्रोग्राम को कोई संदेश नहीं मिला और उस अपवाद को फेंक दिया।

यह स्प्रिंग फ्रेमवर्क के रेस्टेमप्लेट के बारे में एक उदाहरण है। मुद्दा यह है कि, भले ही संदेश बॉडी HTTP युक्ति द्वारा निषिद्ध नहीं है, फिर भी कुछ क्लाइंट या सर्वर लाइब्रेरी या फ्रेमवर्क अभी भी पुराने चश्मे का अनुपालन कर सकते हैं और GET अनुरोध से संदेश निकाय को अस्वीकार कर सकते हैं।

Comments

आप यहाँ युक्ति या टिप्पणियों को सही ढंग से नहीं पढ़ रहे हैं। ग्राहकों और अनुरोध शरीर छोड़ने सर्वर है कल्पना के भीतर। GET अनुरोध निकायों का उपयोग न करें।

— Evert

@ क्या मैंने टिप्पणियों को सही ढंग से नहीं पढ़ा या आपने नहीं किया? :) यदि आप पॉल मॉर्गन के उत्तर (शीर्ष हिटिंग उत्तर) तक स्क्रॉल करते हैं और टिप्पणियों को ध्यान से पढ़ें, तो आपको यह पता चलेगा: "RFC2616 को" HTTP / 1.1 युक्ति "के रूप में संदर्भित अब अप्रचलित है। 2014 में इसे बदल दिया गया था। RFCs 7230-7237। उद्धरण "संदेश-निकाय SHOULD को अनदेखा किया जा सकता है जब अनुरोध को संभालना हटा दिया गया हो। यह अब बस है" अनुरोध संदेश फ़्रेमिंग विधि शब्दार्थ से स्वतंत्र है, भले ही विधि संदेश शरीर के लिए किसी भी उपयोग को परिभाषित न करे। ... "

— झोउ

@ इसके अलावा, मैं अपने स्प्रिंग-बूट बैकएंड का परीक्षण करने के लिए REST परीक्षण उपयोगिता "आराम-आश्वासन" का उपयोग कर रहा था। बाकी का आश्वासन और स्प्रिंग-बूट सर्वर-साइड ने GET अनुरोध के लिए Json निकाय को रखा! केवल स्पिंग-फ्रेमवर्क की रेस्टेमप्लेट जीईटी अनुरोधों से शरीर को गिरा देती है, इसलिए स्प्रिंग-बूट, रेस्ट-एश्योर्ड और रेस्टेमप्लेट, जो गलत है / हैं?

— झोउ

@ अंतिम, लेकिन पट्टे पर नहीं, मैंने लोगों से GET अनुरोधों में शरीर का उपयोग करने का आग्रह नहीं किया, इसके विपरीत, मैं सुझाव दे रहा था कि स्पिंग-फ्रेमवर्क के रिस्टेमप्लेट के स्रोत कोड का विश्लेषण करके ऐसा नहीं किया, तो आपने मुझे वोट क्यों नहीं दिया? का जवाब?

— झोउ

मैंने आपके उत्तर को अस्वीकार नहीं किया। मैं केवल यह स्पष्ट कर रहा हूं कि कोई भी HTTP कार्यान्वयन GET अनुरोध को छोड़ रहा है ।

— एवर्ट