चाहिए API कॉल GET या POST

Question

हो मैंने देखा है कि चहचहाना एपीआई उपयोग जैसे कुछ एपीआई सब कुछ करने के लिए तरीके मिलता है, तो पैरामीटर इस

http://api.twitter.com/1/statuses/user_timeline.json?screen_name=screenname 

तरह यूआरएल में पारित कर रहे हैं मैं कुछ सवाल हैं और टिप्पणी की सराहना करेंगे या सुधार:

1. मैंने हमेशा सोचा कि जीईटी का उपयोग करना एक अच्छा विचार नहीं है और यह POST का उपयोग करना बेहतर है।

2. एपीआई I कोडिंग के लिए एक कुंजी की आवश्यकता है, और मुझे नहीं लगता कि यह यूआरएल में भेजना अच्छा विचार है। तो क्या POST पैरामीटर और यूआरएल पैरामीटर दोनों मिश्रण करना संभव है?

3. एक अन्य समस्या

   मैंने सुना है कि यूआरएल एक अधिकतम लंबाई है, इसलिए मुझे लगता है कि इस तरह से बाहर निकलना होगा, या वहाँ एक समाधान

4. समस्या सिर्फ मैं पोस्ट के साथ दिखाई दे रही है (और जो मुझे लगता है कि ट्विटर जैसी साइट जीईटी के साथ क्यों गई) यह है कि अनुरोध सीधे ब्राउज़र से नहीं बनाया जा सकता है। अगर मैं इस पर गलत हूं तो मुझे सही करें।

---

अपडेट: जो कोई मुझे इस मंथन की मदद कर रहा है के लिए धन्यवाद। मेरे पास कुछ टिप्पणियों को स्पष्ट करने के लिए कुछ अपडेट हैं।

1. जब मैं URL में कुंजी भेजने के लिए इच्छुक नहीं के बारे में बात कर रहा था, कि मैं क्या मतलब है कि मैं नहीं है कुंजी, बुकमार्क चाहते हैं, तो एक उपयोगकर्ता बुकमार्क करने के लिए एक फोन नहीं थे कि मैं डॉन है ' टी कुंजी बिल्कुल खुलासा नहीं चाहता है। तो मुझे जवाब से लगता है, मैं इसे हेडर फ़ील्ड में भेज सकता हूं? कोई अन्य विकल्प?

2. मैं POST requests can't be made from the urlhttp://example.com/api/op.json?param=value में के रूप में स्पष्ट करने के लिए जब मैंने कहा कि पोस्ट अनुरोध can't be made from the browser, मैंने कहा जाना चाहिए था कि, चाहते हैं। क्षमा करें, मैं misspoke, स्पष्ट होना चाहिए था।

3. पुन यह RESTful या नहीं है कि क्या: मैं एक MVC रूपरेखा है कि क्रिया और यूआरएल का पता लगाने का ख्याल रखा के साथ पहले RESTful किया है example.com/entry/1, या example.com/entry/ और http क्रियाओं की तरह लग रही समाप्त हो गया क्या नियंत्रित संचालन किया जा रहा है कर रहे हैं प्रदर्शन (निर्माण, अद्यतन, हटाएं, सूची)। मैंने सोचा, व्यावहारिक रूप से, कि RESTful क्रूड-जैसे डेटा के लिए सबसे उपयोगी था (प्रवेश बनाएं, प्रवेश प्राप्त करें, प्रवेश दर्ज करें, प्रविष्टि हटाएं, सभी प्रविष्टियां दिखाएं)। तो अगर मुझे क्रूड की जरूरत नहीं है, तो क्या मुझे आरईएसटी चाहिए? मेरा सवाल: यदि कोई कॉल केवल इनपुट देता है और आउटपुट देता है, तो क्या इस एपीआई को रीस्टफुल करने की आवश्यकता है? यूआरएल रीस्टफुल नहीं दिखता है, तो क्या कार्यान्वयन में कुछ और है जो इसे रीस्टफुल कर सकता है?

4. यूआरएल आकार के अनुसार, आपने but if you're seriously concerned about it you probably should rethink your API. GET requests shouldn't be sending that much data to the server. पर टिप्पणी की तो मेरे पास यह उदाहरण है: उपयोगकर्ता एक बड़ी फाइल भेजना चाहता है। सर्वर पर, मैं डेटाबेस में फ़ाइल दर्ज नहीं करूँगा या इसे सहेज नहीं सकता (इसलिए मानकों के अनुसार मैं डेटा पोस्ट नहीं कर रहा हूं), लेकिन शायद मैं हूं (इन्हें जल्दी से उदाहरणों के बारे में सोचा जाता है, इसलिए कृपया उन्हें कम करें) :

   • (क) फ़ाइल के मेटाडाटा पढ़ने और यह लौटने (कि GET या POST होना चाहिए), या
   • (ख) मैं मेटाडाटा पढ़ रहा हूँ और फ़ाइल पर metada को संशोधित करने और लौटने संशोधित फ़ाइल (वह प्राप्त या पोस्ट होना चाहिए)।
   • तो यह एक उदाहरण है कि मुझे बड़े डेटा भेजने की आवश्यकता क्यों हो सकती है। सवाल यह है कि (ए) और (बी) जीईटी या पोस्ट ऑपरेशंस माना जाता है? और यही कारण है कि मैं यूआरएल अधिकतम लंबाई

Answer 1

देखने के सर्वर बिंदु से के बारे में पूछ रहा था, यह बात बहुत ज्यादा नहीं क्या तंत्र प्रयोग किया जाता है है। सर्वर पक्ष पर एकमात्र सार्थक अंतर यह है कि जीईटी अनुरोध आमतौर पर पूरी तरह से लॉग होते हैं (पैरामीटर के साथ), जबकि POST अनुरोधों का डेटा आमतौर पर लॉग नहीं होता है (लेकिन यह कस्टम सर्वर के लिए नियम नहीं है, जो कुछ भी लॉग या लॉग नहीं कर सकता है) ।

इसके अलावा, कई मामलों में आप जीईटी या पोस्ट का उपयोग कर सकते हैं और सर्वर दोनों मामलों को सही ढंग से और पारदर्शी रूप से संभाल लेगा। मिक्सिंग भी संभव है, और अधिकांश सर्वर पारदर्शी रूप से भी संभाल लेंगे।

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

यूआरएल में अधिकतम है। लंबाई (4K एक आम सीमा होने के लिए, लेकिन अनिवार्य नहीं है), हाँ। कुछ प्रॉक्सी और कुछ सर्वर (और शायद कुछ क्लाइंट) बड़े यूआरएल को संभालने में असमर्थ हो सकते हैं या कृत्रिम प्रतिबंध (हमलों को रोकने के लिए) हो सकते हैं।

मुझे यकीन नहीं है कि मैं "ब्राउज़र से सीधे अनुरोध नहीं किया जा सकता" के बारे में आपका विचार समझा। जब आप ब्राउज़र में एक वेब फॉर्म भरते हैं, तो यह सर्वर पर पोस्ट किया जाता है (जब तक जावास्क्रिप्ट या AJAX नियोजित नहीं होता है, तो उनका उपयोग करने के कारण आपको एक GET अनुरोध मिल सकता है)।

Answer 2

1. मैंने हमेशा सोचा कि जीईटी का उपयोग करना एक अच्छा विचार नहीं है और यह पोस्ट का उपयोग करना बेहतर है।

जानकारी पढ़ने के लिए जीईटी का उपयोग करें, जानकारी लिखने के लिए पोस्ट करें। अनुरोध प्राप्त करें सर्वर-साइड स्थिति को संशोधित नहीं करना चाहिए, जबकि POST अनुरोध सुरक्षित रूप से ऐसा कर सकते हैं। आमतौर पर लिखने के लिए पढ़ने और पोस्ट के लिए जीईटी का उपयोग करें। आपके एपीआई को शायद दोनों के मिश्रण का उपयोग करना चाहिए, जिसके आधार पर प्रत्येक विशिष्ट एपीआई कॉल करता है।

2. एपीआई I कोडिंग के लिए एक कुंजी की आवश्यकता है, और मुझे नहीं लगता कि यह यूआरएल में भेजना अच्छा विचार है। तो क्या POST पैरामीटर और यूआरएल पैरामीटर दोनों मिश्रण करना संभव है?

POST के माध्यम से डेटा भेजना किसी भी स्तर की सुरक्षा को जोड़ता नहीं है। POST अनुरोधों से अनुरोध प्राप्त कम असुरक्षित हैं; वे समान हैं। निजी डेटा स्थानांतरित करने के लिए, एसएसएल का उपयोग करें।

3. एक अन्य समस्या मैंने सुना है कि यूआरएल एक अधिकतम लंबाई है, इसलिए मुझे लगता है कि इस तरह से बाहर निकलना होगा, या वहाँ एक समाधान

कोई अधिकतम URL लंबाई परिभाषित नहीं है है HTTP मानक द्वारा, हालांकि some browsers एक लगाओ। यह जावास्क्रिप्ट के माध्यम से जीईटी अनुरोध उत्पन्न करते समय शायद कोई फर्क नहीं पड़ता, लेकिन यदि आप इसके बारे में गंभीरता से चिंतित हैं तो आपको शायद अपने एपीआई पर पुनर्विचार करना चाहिए। अनुरोध प्राप्त करें सर्वर पर इतना डेटा नहीं भेजना चाहिए।

4।एकमात्र समस्या जो मैं POST के साथ देख रहा हूं (और जो मैं अनुमान लगा रहा हूं वह है कि ट्विटर जैसी साइट जीईटी के साथ क्यों जाती है) यह है कि अनुरोध सीधे ब्राउज़र से नहीं बनाया जा सकता है। अगर मैं इस पर गलत हूं तो मुझे सही करें।

आपका ब्राउज़र POET अनुरोधों को आसानी से जीईटी अनुरोधों के रूप में उत्पन्न कर सकता है, पता बार के माध्यम से POST अनुरोध सबमिट करना मुश्किल है।

Answer 3

अधिक व्यापक उत्तर है: कृपया REST और सामान्य रूप से HTTP क्रियाएं पढ़ें।

यहाँ अपने प्रश्नों के कुछ कम जवाब हैं:

मुझे हमेशा यही लगता है कि प्राप्त का उपयोग कर एक अच्छा विचार नहीं है और यह उपयोग पोस्ट करने के लिए बेहतर है कि।

यह आपके द्वारा किए जा रहे कार्यों पर निर्भर करता है।

एपीआई मैं कोडिंग कर रहा हूँ एक महत्वपूर्ण आवश्यकता है, और मैं इसे एक अच्छा विचार है URL में इसे भेजने के लिए नहीं लगता। तो क्या दोनों POST पैरामीटर और यूआरएल पैरामीटर दोनों मिश्रण कर सकते हैं?

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

एक अन्य समस्या यह है कि मैं यूआरएल एक अधिकतम लंबाई है सुनना है, इसलिए मुझे लगता है कि कि रास्ते से हट जाओ होगा, या वहाँ एक समाधान

"वैकल्पिक हल" करने के लिए है बड़ी मात्रा में डेटा संचारित करने के लिए POST या PUT जैसे अन्य क्रियाओं का उपयोग करें।

समस्या सिर्फ मैं पोस्ट साथ दिखाई दे रही है (और जो मेरा अनुमान है कि यही वजह है कि एक साइट चहचहाना की तरह प्राप्त साथ चला गया) कि अनुरोध सीधे ब्राउज़र से नहीं बनाया जा सकता है। अगर मैं पर गलत हूं तो मुझे सही करें।

पोस्ट अनुरोध method="POST" के साथ एक साधारण HTML <form> के उपयोग के माध्यम ब्राउज़र से सीधे बनाया जा सकता है।

Answer 4

जैसा कि एनन ने कहा, डेटा पुनर्प्राप्त करने के लिए प्राप्त करें, परिवर्तन/डेटा भेजने के लिए पोस्ट करें, जो आपको http मानक के अनुरूप रखता है। AFAIK, आप जीईटी/पोस्ट पैराम मिश्रण नहीं कर सकते हैं। आप एक ब्राउज़र से एक फॉर्म से एक पोस्ट अनुरोध कर सकते हैं, लेकिन यूआरएल जानकारी पता बार दर्ज करके नहीं। पोस्ट स्ट्रिंग बनाम स्ट्रिंग में एक कुंजी वास्तव में बहुत अलग नहीं है। अगर अनुरोध पारगमन में अवरुद्ध हो जाता है, तो कुंजी किसी भी तरह से समझौता किया जाता है। यदि आप कुंजी को एन्क्रिप्ट करने के लिए सार्वजनिक/निजी कुंजी जोड़ी का उपयोग करते हैं, तो आप उस समस्या को हल कर सकते हैं। और हां, स्ट्रिंग प्राप्त करें अधिकतम लंबाई है, लेकिन पोस्ट करता है, हालांकि आपकी सर्वर सेटिंग्स पर बहुत बड़ा और निर्भर है।

Answer 5

क्यों दोनों का समर्थन नहीं करते? यह सबसे लचीला है। मैंने केवल एक एपीआई (एकाधिक संस्करण) लिखा है, और क्लाइंट और डिबगिंग को लागू करते समय दोनों चर के लिए जीईटी और पोस्ट दोनों का समर्थन करने में मदद मिली है। यह मिश्रण और जीईटी और पोस्ट से मेल खाता है। $ _REQUEST का उपयोग करें और किया जाना चाहिए।