JSON REST/RPC इंटरफ़ेस के लिए आईडीएल

Question

हम एक काफी जटिल REST API तैयार कर रहे हैं, जिसमें अधिकांश I/O JSON एन्कोडेड ऑब्जेक्ट्स एक विशिष्ट संरचना के साथ हैं। एक चुनौती जो हमने पाया है वह एपीआई को इस तरह से दस्तावेज करना है जिससे ग्राहकों को सही इनपुट और प्रक्रिया आउटपुट पोस्ट करना आसान हो जाता है। चूंकि इनपुट और आउटपुट दोनों के डेटा के लिए काफी जटिल जेएसओएन ऑब्जेक्ट्स की आवश्यकता होती है, क्लाइंट डेवलपर्स अक्सर आई/ओ ऑब्जेक्ट्स की संरचना से संबंधित बग पेश करते हैं।

इन सभी JSON वेब एपीआई के साथ, मैं एक सामान्य समाधान की उम्मीद करता, लेकिन मुझे एक खोजने में मुश्किल होती है। मैंने json-schema में देखा जो एक जेसन-सत्यापन स्कीमा है लेकिन आईईटीएफ ड्राफ्ट और कार्यान्वयन दोनों काफी अपरिपक्व प्रतीत होते हैं (भले ही वे थोड़ी देर के लिए रहे हैं, जो एक अच्छा संकेत नहीं है)।

Protocol Buffers और Apache Avro द्वारा थोड़ा अलग दृष्टिकोण प्रदान किया जाता है, जहां स्कीमा सत्यापन के लिए उपयोग नहीं किया जाता है, लेकिन वास्तव में संदेश के एन्कोडिंग/डिकोडिंग के लिए आवश्यक होता है। इन 2 में से, एवरो को सीमित दस्तावेज़ीकरण और कार्यान्वयन लगता है। ProtoBuf बेहतर लगता है, लेकिन मुझे यकीन नहीं है कि यह JSON एपीआई कॉल करने के लिए ब्राउज़र में उपयोग करने के लिए वास्तव में उपयुक्त है?

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

संपादित करें: इस विषय के 6 महीने बाद हमें mongoose मिला, जो कि हम जो देखने के लिए बहुत करीब थे।

Answer 1

डगलस क्रॉकफ़ोर्ड से ईमेल द्वारा प्राप्त एक उत्तर के नीचे।

मैं इनपुट सत्यापन के विकल्प के रूप में स्कीमा में विश्वास नहीं कर रहा हूं। ऐसे गुण हैं जिन्हें वाक्यविन्यास से सत्यापित नहीं किया जा सकता है। मुझे लगता है कि कि एक्सएमएल गलत तरीके से एक तरीका था।

यदि आपके प्रारूप बहुत जटिल हैं, तो मैं उन्हें को सरल बनाने पर विचार करूंगा।

Answer 2

मैं कहूंगा कि आपके अंतिम प्रश्न का उत्तर हाँ है। यदि आपको जेएसओएन "स्कीमा" को बाधित और दस्तावेज करने का कोई तरीका चाहिए, तो आप पहली जगह एक्सएमएल के साथ क्यों नहीं गए? पार्स करना इतना कठिन नहीं है, और इसके लिए एक स्कीमा को लागू करने में सक्षम होना एक बड़ा फायदा है।

Answer 3

एक्सएमएल कई तरीकों से रीस्टफुल सेवाओं के लिए बेहतर है। इसमें मूल लिंकिंग (<link href= है, उन सभी HATEOAS प्रशंसकों के लिए), मूल भाषा समर्थन (lang="en") और एक महान पारिस्थितिक तंत्र है।

भविष्य के प्रमाणन और भविष्य के एपीआई रिफैक्टरिंग के लिए यह भी बेहतर है। इस परिवर्तित:

<profile> 
    <username>alganet</username> 
</profile> 

अधिक उपयोगकर्ता नाम का समर्थन करने के लिए:

<profile> 
    <username>alganet</username> 
    <username>alexandre</username> 
</profile> 

भी बहुत कुछ मौजूदा ग्राहकों XML का उपयोग को तोड़ने के बिना करने के लिए सरल है। JSON उस पर मुश्किल है।

यदि आपको वास्तव में JSON की आवश्यकता है, तो JSON-Schema जाने का तरीका है। यह अपरिपक्व है, लेकिन मुझे उस मामले पर कुछ भी बेहतर नहीं पता है।हो सकता है कि आपके उपभोक्ता एक्सएमएल और जेएसओएन के बीच चयन कर सकें, ताकि वे सामग्री वार्तालाप का उपयोग करके एक छोटे पेलोड (जेएसओएन) या रीस्टफुल कैंडीज (एक्सएमएल) के बीच चयन कर सकें।

Answer 4

ऐसे सिस्टम मौजूद हैं और मैं उनमें से एक का लेखक हूं। इसे Piqi-RPC कहा जाता है और यह HTTP पर आरपीसी-शैली एपीआई के लिए इनपुट और आउटपुट पैरामीटर के आईडीएल-आधारित सत्यापन करता है।

यह JSON, एक्सएमएल और इनपुट और HTTP पोस्ट अनुरोध के उत्पादन के लिए डेटा प्रतिनिधित्व स्वरूपों के रूप में गूगल प्रोटोकॉल बफ़र का समर्थन करता है। ग्राहक तीनों प्रारूपों में से किसी एक का उपयोग करना चुन सकते हैं और मानक Accept और Content-Type HTTP शीर्षलेख का उपयोग करके अपनी पसंद निर्दिष्ट कर सकते हैं।

तो, हां, सिद्धांत रूप में, आप सही दिशा में देख रहे हैं। हालांकि, फिलहाल, पिक्की-आरपीसी केवल एर्लांग में सर्वर लिखने का समर्थन करता है और यदि आप एक अलग स्टैक का उपयोग करते हैं तो यह आपके लिए बहुत उपयोगी नहीं होगा। मैंने सुना है कि अपाचे थ्रिफ्ट भी HTTP परिवहन पर जेएसओएन का समर्थन करता है, लेकिन मैंने जांच नहीं की है। एक अन्य प्रकार की इसी प्रणाली जिसे मैं जानता हूं (एरलांग के लिए भी) को UBF कहा जाता है। मैंने जावा के लिए पुस्तकालयों के बारे में सुना है जो प्रोटोकॉल बफर विनिर्देश (उदा। http://code.google.com/p/protostuff/) के आधार पर JSON को पार्स और मान्य कर सकते हैं।

विचार ही नया किया जा रहा से दूर है, लेकिन वहाँ कई प्रणालियों है कि यह व्यवहार में संपर्क नहीं कर रहे हैं। यह एक चुनौतीपूर्ण समस्या है।

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

Piqi project और Piqi-RPC है, जो इसे पर आधारित है, के आसपास कई काफी सरल प्रतीति का निर्माण कर रहे हैं:

• DLL स्पष्ट रूप से किसी विशेष डेटा प्रतिनिधित्व प्रारूप से बंधा या चारों ओर निर्मित होने की जरूरत नहीं है यह। इसके बजाए, ऐसी भाषा काफी सार्वभौमिक हो सकती है और व्यावहारिक उपयोग-मामलों (जैसे क्रॉस-भाषा डेटा क्रमबद्धता और डेटा सत्यापन) और डेटा प्रारूपों (जैसे JSON, XML, प्रोटोकॉल बफर) की विस्तृत श्रृंखला को कवर कर सकती है।

• RPC शैली संचार के लिए आईडीएल सार्वभौमिक DDL के शीर्ष पर एक पतली, ज्यादातर वाक्यात्मक परत के रूप में लागू किया जा सकता।

• इस तरह आईडीएल और इंटरफ़ेस विनिर्देशों परिवहन नास्तिक हो सकता है।

HTTP पर आरपीसी-शैली एपीआई की तुलना में HTTP पर रीस्ट-स्टाइल एपीआई का बोलना।

आरपीसी-शैली एपीआई के साथ, सेवा डेवलपर या स्वचालित सिस्टम को तीन चीजों को सत्यापित करना होता है: फ़ंक्शन का नाम (कुछ सेवा नामकरण योजना के अनुसार), इनपुट और, यदि आप ऐसा करते हैं, तो आउटपुट।

रीस्ट-स्टाइल एपीआई के मामले में, लोगों को किसी भी अच्छे कारण के लिए परेशानी नहीं होती है। अब, वे एक बहुत अधिक चीजें मान्य करने के लिए: (सभी HTTP पद्धति के लिए) यूआरएल क्षेत्रों में इनकोडिंग डायनेमिक पैरामीटर और यूआरएल क्वेरी स्ट्रिंग (केवल HTTP GET प्रणाली के लिए), HTTP विधि पत्राचार (सहित मनमाने ढंग से जटिल URL सिंटैक्स, चाहे वह करना चाहिए जाओ, पोस्ट करें, पुट, हटाएं, आदि), HTTP बॉडी जब कुछ पैरामीटर वहां जाते हैं (कभी-कभी वे JSON और XML में प्रतिनिधित्व पैरामीटर के लिए मैन्युअल रूप से दो बार करते हैं), कस्टम HTTP शीर्षलेख, और अलग-अलग सेवा प्रलेखन। कल्पना कीजिए कि एक आईडीएल सभी का समर्थन करता है!