ट्विटर एपीआई * वास्तव में * रीस्टफुल है?

Question

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

मेरे सीखने के प्रयास के हिस्से के रूप में, मैं आरईएसटी के कुछ ऑनलाइन उदाहरणों पर विशेष रूप से इस मामले में ट्विटर देख रहा हूं। उनके API documentation में, वे अपने विभिन्न "आरईएसटी एपीआई तरीके" पर चर्चा करते हैं।

मैं तर्कसंगत बनाने के साथ संघर्ष कर रहा हूं कि वास्तव में इनमें से अधिकतर वास्तव में विश्वसनीय हैं, एक विश्वसनीय यूआरएल संरचना से परे। उदाहरण के लिए, उदाहरण के लिए, http://twitter.com/favorites पर एक सरल GET अनुरोध पर विचार करें।

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

उम्मीद है कि मेरे प्रश्न के लिए पर्याप्त संदर्भ प्रदान करता है - क्या इसे वास्तव में "आरईएसटी" कहा जा सकता है? मुझे लगता है कि वेब ब्राउज़र और एप्लिकेशन सर्वर के बीच तथाकथित पुनर्नवीनीकरण कार्यान्वयन का 9 0% इस असंगतता को प्रदर्शित करता है, जहां सर्वर पर संग्रहीत क्लाइंट स्टेटस पर प्रतिबंधों को नजरअंदाज कर दिया जाता है।

Answer 1

ट्विटर हर आरईएसटी बाधा को तोड़ देता है। प्रमाणीकृत उपयोगकर्ता के आधार पर http://twitter.com/favorites के विभिन्न परिणामों को लौटने का आपका उदाहरण ट्विटर की "संसाधन पहचान" बाधा का उल्लंघन करने का एक उदाहरण है। प्रत्येक दिलचस्प संसाधन में एक अद्वितीय पहचानकर्ता होना चाहिए। मेरे ट्विटर पसंदीदा और आपके ट्विटर पसंदीदा दो अलग-अलग संसाधन हैं और इसलिए दो अलग-अलग यूआरआई होना चाहिए।

यह वास्तव में idempotency से संबंधित नहीं है। Idempotency एक ही अनुरोध को कई बार करने में सक्षम होने के बारे में है और इसका एक ही प्रभाव है। यहां तक ​​कि ट्विटर भी बेवकूफी का सम्मान करता है। अगर मैं अपने पसंदीदा कई बार प्राप्त करता हूं, तो भी मुझे अपने पसंदीदा वापस मिलते हैं। मैं कितनी बार GET परिणाम को प्रभावित नहीं करता है।

ट्विटर कई अन्य तरीकों से हैं जिनमें ट्विटर ने पिछली बाधाओं को तोड़ दिया। इनमें से कई मुद्दों को पहले एसओ पर कवर किया गया है।

अद्यतन ट्विटर एपीआई दस्तावेज़ों को थोड़ा और अधिक समझने के बाद वास्तव में एक वैकल्पिक यूआरआई प्रारूप है जो पसंदीदा संसाधन की उचित पहचान करता है। Here वे की तरह एक URL बनाने के लिए कैसे पता चलता है:

http://api.twitter.com/1/favorites/bob.json 

यह अभी भी RESTful किया जा रहा से एक लंबा रास्ता है, लेकिन कम से कम यह है कि सही दिशा में एक कदम है।

Answer 2

इस संदर्भ में, बेवकूफता एक मुश्किल शब्द है। यहां तक ​​कि यदि आप एक व्यक्तिगत ट्वीट पुनर्प्राप्त कर रहे थे, तो भी एक अलग परिणाम मिलेगा यदि वह ट्वीट संपादन योग्य था और किसी ने इसे संपादित किया था। एक सूची पुनर्प्राप्त करते समय, मैं निश्चित रूप से एक ट्वीट को सबसे वर्तमान सूची पुनर्प्राप्त करने की उम्मीद करता हूं।

मूर्खता के बारे में सोचने के लिए साइड इफेक्ट्स के बिना कुछ करने की क्षमता के रूप में यह अधिक उपयोगी हो सकता है। तो इस अर्थ में एक जीईटी बेवकूफ है, लेकिन एक पोस्ट नहीं है।

From Wikipedia:

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

इसके अलावा from Wikipedia:

तरीके डाल दिया और DELETE, को idempotent जा परिभाषित कर रहे हैं जिसका अर्थ है कि कई समान अनुरोध एक अनुरोध के रूप में ही प्रभाव होना चाहिए।

इसके विपरीत, POST पद्धति नहीं है जरूरी idempotent, के बाद से एक समान पोस्ट अनुरोध भेजने कई बार आगे स्थिति को प्रभावित या आगे दुष्प्रभाव हो सकता है (जैसे वित्तीय लेन-देन के रूप में [उदाएक ग्राहक को उसी उत्पाद के लिए गलती से दो बार चार्ज किया जाता है])।

यह भी देखें:

मैं कैसे मेरी पत्नी
http://tomayko.com/writings/rest-to-my-wife

Answer 3

तकनीकी तौर पर करने के लिए बाकी समझाया, नहीं, यह नहीं RESTful है। यह एक चीज के लिए stateless (ए.के.ए. idempotent जैसा आपने उल्लेख किया है) नहीं है।

Answer 4

REST FAQ बताते हैं, "आरईएसटी" शब्द का उपयोग विभिन्न प्रकार की चीजों को कवर करने के लिए किया जाता है, जिसमें एक यथार्थवादी शैली में संरचित राज्यव्यापी अनुप्रयोग शामिल हैं। चूंकि राज्य को सर्वर पर संग्रहीत करने के बजाए उपयोगकर्ता द्वारा कुकी में ज्यादातर पारित किया जा रहा है, इसे रीस्टफुल माना जाता है। रॉय फील्डिंग (जिसने आरईएसटी का आविष्कार किया) commented कि जब तक पूरे राज्य को सर्वर पर राज्य के संदर्भ के बजाय उपयोगकर्ता द्वारा पारित किया जा रहा है, तो यह सही है, क्योंकि उसी जीईटी अनुरोध से वही परिणाम वापस आ जाएगा। ट्विटर की आरईएसटी एपीआई ऐसा करने के करीब है, लेकिन वहां 100% नहीं है। यह सख्ती से "आरईएसटी" का मूल अर्थ नहीं है, लेकिन इंटरफेस और सामान्य दर्शन इसी तरह के समान हैं कि आम तौर पर उसी छतरी के नीचे खींचा जाता है।

Answer 5

documentation पर देखकर, "विधि" शब्द का उपयोग शायद एक अच्छा संकेत है कि क्या एपीआई वास्तव में विश्वसनीय है या नहीं। ऐसे कुछ संसाधन हैं जो वास्तव में friends/<user-id> या favourites/<user-id> जैसे योग्यता प्राप्त कर सकते हैं, लेकिन अधिकांश संसाधन वास्तव में केवल account/update_profile_image जैसे प्रक्रियाएं हैं।

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

Answer 6

ट्विटर एपीआई पढ़ना मुझे समझ में आता है कि रीस्टफुल एपीआई कुछ हफ्तों में अप्रचलित हो जाएगा। इसके बजाय आपको OAuth प्रमाणीकरण विधि का उपयोग करना चाहिए।