2013-10-09 10 views
13

मेरी HTTP API में, अंतिम बिंदुओं में से एक एक यादृच्छिक रूप से जनरेट मूल्य वापस चाहिए और मूल्य endpoint की प्रमाणीकृत फोन करने वाले के साथ संबद्ध किया जाएगा। वर्तमान में, मेरे पास निम्न संरचना है:खाली HTTP POST अनुरोध या प्राप्त अनुरोध पर HTTP एपीआई के माध्यम से एक यादृच्छिक मूल्य उत्पन्न करने के लिए

GET http://example.com/random-ticket HTTP/1.1 
Authorization: Basic base64-encoded-basic-auth-value 
Accept: application/json 
Host: example.com 

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Content-Type: application/json; charset=utf-8 
Date: Thu, 03 Oct 2013 07:25:56 GMT 
Content-Length: 59 

{"user-ticket":"Pfa42634e-1a2e-4a7d-84b9-2d5c46a8dd81"} 

यादृच्छिक मूल्य पुनर्प्राप्त करने के लिए एक GET अनुरोध जारी किया गया है। हालांकि, HTTP GET calls should be idempotent और मेरा उपरोक्त कार्यान्वयन उस नियम का पालन नहीं कर रहा है। दूसरी तरफ, मुझे यकीन नहीं है कि एक खाली संदेश निकाय के साथ HTTP POST अनुरोध जारी करना ठीक है या नहीं। HTTP किताब से संचालन के इस प्रकार के प्रदर्शन के सही तरीके से

क्या है?

उत्तर

15
  • सुरक्षित => कि सर्वर पर राज्य का एक परिवर्तन में कॉल का परिणाम है।
  • Idempotent => चाहे एकाधिक कॉल सर्वर पर एक ही बदलाव के परिणामस्वरूप हों।

तो सवाल यह डेटा कि लौटा दिया जाता है नहीं है। बल्कि यह सर्वर राज्य है: इसलिए यदि आप सर्वर पर यह मान भंडारण कर रहे हैं इस अवस्था में एक परिवर्तन में परिणाम है, तो इसे पाने के लिए उपयुक्त नहीं है। अन्यथा यदि यह डेटा लौटाया गया है, तो यह ठीक है। http://stackoverflow.com पर कॉल करें यदि 10 मिनट अलग कहा जाता है तो अलग-अलग डेटा लौटाता है।

चलिए एक और उदाहरण देखें, घड़ी सेवा जो वर्तमान समय देता है। हर बार जब आप कॉल करते हैं, तो आपको एक अलग मूल्य मिलता है लेकिन कॉल के परिणामस्वरूप सर्वर पर राज्य में बदलाव नहीं होता है क्योंकि घड़ी की स्थिति अलग-अलग रखी जाती है। तो यहां जीईटी का उपयोग करना एक अच्छा विकल्प है।

+0

संसाधन बनाना! = सर्वर पर भंडारण मूल्य –

+0

@FilipW मैंने एक मूल्य संग्रहित नहीं किया था। यह ** राज्य बदल रहा है **। – Aliostad

+0

धन्यवाद दोस्तों। यह उत्तर अधिक वर्णनात्मक है और मेरे सभी भ्रम को हटा दिया गया है। – tugberk

11

बिल्कुल HTTP एक खाली शरीर के साथ पोस्ट के उपयोग पर रोक लगाने में कुछ भी नहीं है।

इसके अलावा, संदेश एक प्रतिनिधित्व है, जो शरीर + हेडर है वहन करती है। आपके मामले में शरीर 0 लंबाई है, जो ठीक है, और शीर्षलेख जो उपयोगकर्ता की पहचान करते हैं।

यहाँ चर्चा देखें - http://lists.w3.org/Archives/Public/ietf-http-wg/2010JulSep/0273.html

+0

क्षमा करें, मैंने भ्रम से जीईटी के बारे में बात की! लेकिन यह सवाल सर्वर राज्य है जिसका उल्लेख यहां नहीं किया गया है और यह कुंजी है। – Aliostad

+0

मुझे लगता है कि ओपी काफी जागरूक है कि उसे यहां जीईटी का उपयोग नहीं करना चाहिए, इसलिए मैंने यह बताने की कोशिश की कि उसे POST का उपयोग करने के लिए डरना क्यों नहीं चाहिए –

+0

मुझे इतना यकीन नहीं है। – Aliostad

1

इस मामले में आपको POST का उपयोग करना चाहिए क्योंकि, desgin, GET कॉल कैश किया जा सकता है। खाली पोस्ट बॉडी के बारे में, कोई मुद्दा नहीं है। , 0 और निम्नलिखित कुछ भी नहीं पूरी तरह से कर सकता: ऐसा ही एक परिदृश्य भी पर चर्चा की है: POST with empty body, जिसमें एक पद का उल्लेख है:

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

विली

+2

"जीईटी कॉल कैश किया जा सकता है" जो सही है, लेकिन डेटा स्थिरता के आधार पर आप प्राप्त करना चाहते हैं यानी सर्वर पर डेटा कितनी बार बदलता है। इसलिए आपको उन अनुरोधों को भी प्राप्त हो सकता है जिन्हें आप कैशिंग की अनुमति नहीं देना चाहते हैं। इसके अतिरिक्त, प्रमाणीकृत डेटा के बारे में सोचें जिसे या तो कैश नहीं किया जाना चाहिए। तो आपका कैशिंग तर्क बिल्कुल ठीक नहीं है। – brazo

+2

आप उचित कैश हेडर वापस कर सकते हैं। – Aliostad

4

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

शरीर के बिना पोस्ट करने के लिए, या क्वेरी स्ट्रिंग में पैराम का उपयोग करने के लिए, यह ठीक है। POST के बारे में महत्वपूर्ण बात यह है कि यह 'मई' के परिणामस्वरूप सर्वर में परिवर्तन हो सकता है। यह गारंटी नहीं है कि यह होगा, लेकिन आप यह नहीं मान सकते कि यह एक जीईटी के साथ नहीं होगा। चाहे कोई सामग्री सेट हो या नहीं, इस तथ्य को नहीं बदले कि कोई बदलाव हो सकता है। उदाहरण के लिए एक कल्पित संसाधन "\ counter \ increment" की कल्पना करें। हर बार जब आप इसे पोस्ट करते हैं तो यह बढ़ने के लिए \ counter का कारण बन जाएगा। मैंने कोई पेलोड नहीं भेजा है, लेकिन मैं सर्वर स्थिति में बदलाव कर रहा हूं इस प्रकार यह पोस्ट या पुट होना चाहिए।

संबंधित मुद्दे