आरईएसटी के साथ बाल विभाजित करना: क्या मानक JSON REST API हैटोज़ का उल्लंघन करता है?




(5)

मैं आज सुबह आरईएसटी पर कुछ पढ़ रहा था और मैं हैटओएएस सिद्धांत ("हाइपर्मियाडिया अनुप्रयोग के इंजन के रूप में") में आया था

आरईएसटी विकिपीडिया पेज का उद्धरण:

ग्राहक केवल उन क्रियाओं के माध्यम से राज्य संक्रमण करते हैं जो सर्वर द्वारा हाइपर्मियाडिया के भीतर गतिशील रूप से पहचाने जाते हैं (उदाहरण के लिए हाइपरटेक्स्ट के भीतर हाइपरलिंक्स द्वारा)। एप्लिकेशन को सरल फिक्स्ड एंट्री पॉइंट्स को छोड़कर, क्लाइंट यह नहीं मानता कि किसी भी विशेष क्रिया सर्वर से प्राप्त प्रस्तुतियों में वर्णित किसी भी विशेष संसाधन के लिए उपलब्ध होगी।

और रॉय फील्डिंग का ब्लॉग :

... यदि आवेदन स्थिति (और इसलिए एपीआई) का इंजन हाइपरटेक्स्ट द्वारा संचालित नहीं किया जा रहा है, तो यह रीस्टफुल नहीं हो सकता है और एक आरईएसटी एपीआई नहीं हो सकता है। अवधि।

मैंने इसे इस प्रकार पढ़ा है: क्लाइंट केवल सर्वर (हाइपरटेक्स्ट) से प्रतिक्रिया के शरीर से उपलब्ध कार्यों के आधार पर राज्य परिवर्तनों का अनुरोध कर सकता है।

एक HTML दुनिया में, यह सही समझ में आता है। ग्राहक केवल हाइपरटेक्स्ट (एचटीएमएल) के माध्यम से उपलब्ध लिंक के आधार पर राज्य परिवर्तन (नए क्रिया / पृष्ठ) का अनुरोध करने में सक्षम होना चाहिए।

जब संसाधन को अन्य तरीकों से दर्शाया जाता है - जैसे जेएसओएन, एक्सएमएल, वाईएएमएल इत्यादि। यह इतना स्पष्ट नहीं है।

आइए एक उदाहरण "आरईएसटी" जेएसओएन एपीआई लें:

मैं एक POST अनुरोध भेजकर एक नया संसाधन (उदाहरण के लिए एक नई टिप्पणी) बनाते हैं

/comments.json? # with params...

सर्वर के साथ प्रतिक्रिया करता है:

# Headers
HTTP/1.1 201 Created 
Location: http://example.com/comments/3
Content-Type: application/json; charset=utf-8
... Etc.

# Body
{"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"}

मुझे पता है कि अब मैं शीर्ष पर वापस आईआरआई में इस टिप्पणी तक पहुंच सकता हूं: http://example.com/comments/3.json

जब मैं http://example.com/comments/3.json हूं तो मैं देखता हूं:

{"id":3,"name":"Bodacious","body":"An awesome comment","post_id":"1"}

मान लीजिए कि एपीआई के दस्तावेज मुझे बताता है कि मैं एक ही यूआरआई को एक डेली अनुरोध भेजकर इस टिप्पणी को हटा सकता हूं। यह "आरईएसटी" एपीआई के बीच काफी आम है।

तथापि:

GET http://example.com/comments/3.json पर सर्वर से प्रतिक्रिया मुझे DELETE अनुरोध भेजकर टिप्पणी को हटाने में सक्षम होने के बारे में कुछ भी नहीं बताती है। यह सब मुझे संसाधन दिखाता है।

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

यहां, ग्राहक यह मान रहा है कि इस संसाधन के लिए DELETE कार्रवाई (और संभव अन्य) उपलब्ध हैं और यह जानकारी सर्वर से पहले प्राप्त नहीं हुई है।

क्या मैंने हेटोआस को गलत समझा है या क्या मैं उपरोक्त वर्णन से मेल खाने वाले एपीआई की तुलना में सही कह रहा हूं, सख्ती से नहीं, एक आरईएसटी एपीआई हो सकता है?

मुझे पता है कि आरईएसटी का 100% अनुपालन हमेशा संभव नहीं है या जाने का सबसे व्यावहारिक तरीका नहीं है। मैंने इस सवाल को पूरी तरह से रीस्ट के पीछे सिद्धांत के बारे में अपनी जिज्ञासा को पूरा करने के लिए पोस्ट किया है, वास्तविक दुनिया के सर्वोत्तम अभ्यास पर सलाह के लिए नहीं।


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

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

चूंकि हाइपरटेक्स्ट हैटेट्स में 'हाइपरमेडिया' का जिक्र करते समय अधिकांश लोगों का मतलब है, हाइपरटेक्स्ट की विशेष शक्ति यह अन्य मीडिया से जुड़ने की क्षमता है। इसके अलावा, चूंकि एचटीटीपी / एचटीएमएल के माध्यम से अधिकांश अनुभव हाइपरटेक्स्ट यह सोचने के लिए कई लोगों का नेतृत्व करता है कि हाइपरलिंक केवल एंकर टैग या लिंक टैग के माध्यम से एक प्रतिक्रिया इकाई के शरीर के भीतर संभव है - लेकिन ऐसा नहीं है।

यदि परिवहन प्रोटोकॉल HTTP है तो आवेदन स्थिति हेडर के माध्यम से संचारित की जानी चाहिए। विशेष रूप से, अर्थात् प्रदान करने के लिए 'rel' विशेषता वाले एक या अधिक 'लिंक' हेडर। ऑलॉ हेडर के साथ लिंक हेडर HTTP तंत्र हैं जो अगले संभावित राज्य संक्रमण क्या हैं और उन्हें एक्सेस करने के बारे में कैसे संचार करते हैं।

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

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

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

उम्मीद है की यह मदद करेगा। बीटीडब्ल्यू अगर आप एपीआई के लिए एक अच्छा मानव ब्राउज़र चाहते हैं तो Google 'Paw API Browser'


एक hypermedia प्रकार के रूप में JSON अनुप्रयोग प्रवाह के लिए एक पहचानकर्ता परिभाषित नहीं करता है। एचटीएमएल में लिंक और फॉर्म टैग है जो एक प्रक्रिया के माध्यम से उपयोगकर्ता को मार्गदर्शन करता है।

यदि आपका आवेदन केवल PUT, POST, DELETE, संसाधन पर प्राप्त होता है, तो आपका दस्तावेज़ आसानी से समझा सकता है।

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

आप एचटीएमएल / एक्सएचटीएमएल का उपयोग कर सकते हैं, अपना खुद का 'बोडायस + जेसन' बनाएं या कुछ और इस्तेमाल करें। यहां सभी अलग-अलग मीडिया प्रकार http://www.iana.org/assignments/media-types/index.html

मैं एचएएल का उपयोग कर रहा हूं और इसमें एक सुंदर सक्रिय समूह है। यहां लिंक हैं।

http://www.iana.org/assignments/media-types/application/vnd.hal+json

http://stateless.co/hal_specification.html

पुस्तक "एचटीएमएल 5 और नोड के साथ बिल्डिंग हाइपरमेडिया एपीआई" हाइपर्मियाडिया और मीडिया प्रकारों में गहरी हो जाती है। यह दिखाता है कि XML या JSON में किसी विशिष्ट या सामान्य उद्देश्य के लिए मीडिया प्रकार कैसे बनाएं।


जेएसओएन के लिए हैटओएएस को हल करने का प्रयास एक और ठोस (और मई 2013 तक नया) यहां पाया जा सकता है:

JSON API: http://jsonapi.org/


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

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

मुझे JSON-Schema और other आरएफसी जैसे प्रयासों का एहसास है जो जेएसओएन में चीजों को मानकीकृत करने की कोशिश कर रहे हैं, लेकिन इसी दौरान, मूर की बात ने मुझे एक्सएचटीएमएल को एक कोशिश देने के लिए आश्वस्त किया।


एक पूरी तरह से खोजने योग्य जेएसओएन एपीआई जिसे किसी भी आउट-ऑफ-बैंड ज्ञान की आवश्यकता नहीं होती है, क्योंकि आपने इसे बहुत संक्षिप्त रूप से रखा है:

"मैं एक ही यूआरएल के साथ एक टिप्पणी भी हटा सकता हूं, कुछ ऐसा है जो क्लाइंट ऑफ-बैंड जानकारी (दस्तावेज़ीकरण) के माध्यम से जानता है और सर्वर से प्रतिक्रिया द्वारा खोज और संचालित नहीं होता है।"

... पूरी तरह से संभव है। यह सिर्फ एक मानक मानक और एक क्लाइंट की आवश्यकता है जो मानक को समझता है। एचएम-जेसन और एचएम-जेसन ब्राउज़र प्रोजेक्ट देखें:

https://bitbucket.org/ratfactor/hm-json-browser/

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

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





rest