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




(4)

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

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

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

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

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

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

एक 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'


उपलब्ध विधियों / कार्यों के ग्राहक को सूचित करने के लिए Allow-header का उपयोग करने के लिए एक विश्वसनीय समाधान होगा:

> GET /posts/1/comments/1 HTTP/1.1
> Content-Type: application/json
>
< HTTP/1.1 200 OK
< Allow: HEAD, GET, DELETE
< Content-Type: application/json
<
< {
<  "name": "Bodacious",
<  "body": "An awesome comment",
<  "id":   "1",
<  "uri": "/posts/1/comments/1"
< }

फील्डिंग का शोध प्रबंध दो प्रकार के मेटाडाटा सेट करता है: प्रतिनिधित्व मेटाडाटा ; और संसाधन मेटाडाटा

HTTP / 1.1 में संसाधन-मेटाडेटा के रूप में अनुमत-हेडर क्योंकि यह किसी संसाधन की कुछ संपत्ति का वर्णन करता है; यानी यह तरीकों की अनुमति देता है।

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

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

यह एक साफ डिजाइन है; ग्राहक ने एक प्रस्तुति के लिए कहा, और इसके अतिरिक्त संसाधन के बारे में अतिरिक्त मेटाडेटा का पूरा समूह प्राप्त हुआ जो आगे के प्रतिनिधित्व के कुशल अनुरोध को सक्षम बनाता है।

मुझे लगता है कि आपके पास विकिपीडिया आरईएसटी पृष्ठ से उद्धरण कुछ हद तक शब्दों की पसंद में भ्रामक है और यहां मदद नहीं मिली है (एनबी इस सवाल के बाद से इसे बेहतर किया गया है)।

सभी HTTP ग्राहकों को यह मानना ​​है कि अधिकांश संसाधनों के लिए एक जीईटी-विधि उपलब्ध होने की संभावना है। वे ऐसा इसलिए करते हैं क्योंकि जीईटी और हेड के लिए समर्थन HTTP / 1.1 सर्वर के लिए न्यूनतम आवश्यकताएं हैं। इस धारणा के बिना वेब काम नहीं करेगा। यदि कोई ग्राहक जीईटी मान सकता है तो उपलब्ध है, तो क्यों सामान्य विधियों जैसे DELETE , या POST के बारे में अन्य धारणाएं नहीं बनाते?

आरईएसटी और HTTP नेटवर्क पर अनुरोधों की कुल मात्रा को कम करने के लिए विधियों के बुनियादी सेट के बारे में धारणा बनाने की शक्ति का लाभ उठाने का लक्ष्य है; अगर कोई अनुरोध सफल होता है तो आगे संचार की आवश्यकता नहीं होती है; लेकिन अगर अनुरोध '405 विधि अनुमत नहीं है' स्थिति में विफल रहता है, तो क्लाइंट तुरंत अनुरोधों की प्राप्ति में है जो अनुमति-हेडर के माध्यम से सफल हो सकता है:

> ANNIHILATE /posts/1/comments/1 HTTP/1.1
> Content-Type: application/json
>
< HTTP/1.1 405 Method Not Allowed
< Allow: HEAD, GET, DELETE
< Content-Type: application/json
<

यदि HTTP / 1.1 विधियों का मूल सेट पर्याप्त नहीं है तो आप स्वयं को परिभाषित करने के लिए स्वतंत्र हैं। हालांकि, नए तरीकों को परिभाषित करने या संदेश-शरीर में मेटाडेटा डालने से पहले HTTP की उपलब्ध सुविधाओं का उपयोग करके समस्याओं को हल करने के लिए यह सही होगा।


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

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

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

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

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

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


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

JSON API: http://jsonapi.org/





rest