क्या मुझे सर्वर पर XML को पार्स करना चाहिए या एक प्रॉक्सी प्रदान करना चाहिए और ब्राउज़र को पार्स करने देना चाहिए?

Question

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

समग्र डेटा, हालांकि, मूल रूप से दो सेटों में टूट गया है।

1. डेटा का पहला सेट सार्वजनिक है और केवल इसे हर बार अपडेट करने की आवश्यकता होती है, इसलिए इसे सर्वर के सभी उपयोगकर्ताओं के लिए कैश किया जा सकता है, जिससे ट्रैफ़िक काफी कम हो जाता है।
2. डेटा का दूसरा सेट प्रत्येक उपयोगकर्ता के लिए निजी और व्यक्तिगत है। यह डेटा एपीआई में भी अक्सर अपडेट किया जाता है। यह कैशिंग को बहुत कम प्रभावी बनाता है।

स्केलेबिलिटी कारणों से मैं सर्वर का लोड यथासंभव कम रखना चाहूंगा।

मैं अपने सामने दो विकल्प देखता हूं:

1. एक प्रॉक्सी प्रदान करें जिसका उपयोग XML अनुरोधों को 3rd पार्टी सर्वर पर और क्लाइंट और 3rd पार्टी एपीआई के बीच सीधे आगे पीछे करने के लिए किया जा सकता है।
2. क्या सर्वर XML से JSON में रूपांतरण करता है और अनावश्यक जानकारी निकालता है। यह अनिवार्य रूप से हमारे सर्वर के लिए एक नया एपीआई बनाने का मतलब है, जो तीसरे पक्ष के एपीआई से अनुरोधों में अनुवाद करता है

उपयोगकर्ता को डेटा प्रदान करने का सबसे अच्छा तरीका क्या होगा? (दो विकल्पों में से एक होना जरूरी नहीं है)

Comments

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

— SJuan76

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

— amethystdragon

यदि API बार-बार बदलता है, तो संभवतः आपके अपने स्कीमा को घोषित करने के लिए आपके समय की कीमत है और एक सेवा है जो मिडलवेयर के रूप में कार्य करती है, डेटा को आपके क्लाइंट की अपेक्षा में हेरफेर करती है। मुझे लगता है कि सवाल यह है कि 'कौन सा आसान है, क्लाइंट को अपडेट करना या सर्वर को अपडेट करना?'

— हाइपरबोले

यह अक्सर नहीं होता है। यह 10 वर्षों में एक बार बदल गया है।

— amethystdragon

Answer 1

प्रॉक्सी विकल्प लागू करने के लिए सबसे आसान है। आपके पास करने के लिए कोई कस्टम डेवलपमेंट नहीं है, केवल एक ही चीज़ प्रॉक्सी सेट करना है। यह भी सीधा है: बनाए रखने के लिए कोई अतिरिक्त कोड नहीं है, और अगर एपीआई बदलता है, तो आपके पास अपनी ओर से बदलाव करने के लिए कोई बदलाव नहीं है।

एक प्रॉक्सी एक पसंदीदा विकल्प होगा:

• अगर आपको वर्किंग सॉफ्टवेयर को तेजी से शिप करना है। यह एक अच्छा विकल्प बनाता है, उदाहरण के लिए, यदि आप एक फीचर शिप करने वाले थे, लेकिन प्रोजेक्ट के कार्यान्वयन चरण के दौरान पाया गया कि आप क्रॉस-डोमेन AJAX अनुरोध नहीं कर सकते।

• या यदि वर्तमान एपीआई अच्छी तरह से डिज़ाइन किया गया है : आर्किटेक्चर अच्छा है, कॉल बहुत स्पष्ट हैं, प्रलेखन पूर्ण और समझने में आसान है।

• या यदि वर्तमान एपीआई परिवर्तन के अधीन है। यदि यह बदल जाता है, तो आपको जावास्क्रिप्ट कार्यान्वयन को बदलने की आवश्यकता है। यदि एक प्रॉक्सी के बजाय, आप परिणामों को पार्स कर रहे हैं और अपना स्वयं का JSON जेनरेट कर रहे हैं, तो एक जोखिम है कि एपीआई में बदलाव के लिए आपके सर्वर-साइड कोड में बदलाव की आवश्यकता होगी।

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

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

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

• या अगर वर्तमान एपीआई अच्छी तरह से डिज़ाइन नहीं किया गया है। एक मुखौटा पैटर्न की तरह, यह दृष्टिकोण आपको एपीआई को फिर से डिज़ाइन करने में सक्षम बनाता है। यदि मूल एक खराब है, तो एक पहलू होने के कारण एक विरासत एपीआई के मूल लेखकों द्वारा बनाए गए खराब डिजाइन विकल्पों को हल करना संभव हो जाता है। आप बड़े हिस्सों पर भी काम कर सकते हैं, जैसे कि एपीआई की समग्र वास्तुकला, लेकिन विवरणों पर भी, जैसे कि तर्कों के नाम या त्रुटि संदेश।

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

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

आप देख सकते हैं कि मैंने JSON, प्रदर्शन, कैशिंग, आदि के बारे में बात करना छोड़ दिया है। इसके लिए एक कारण है:

• JSON बनाम XML: सही तकनीक चुनने के लिए आप पर निर्भर है । आप इसे JSON पर XML के ओवरहीट को मापने के द्वारा करते हैं, यह समय डेटा को क्रमबद्ध करने और पार्स करने में आसानी लेता है।

• प्रदर्शन: अलग-अलग कार्यान्वयन बेंचमार्क, सबसे तेज़ एक को चुनें, फिर इसे प्रोफाइल करें और प्रोफाइलर के परिणामों के आधार पर इसे अनुकूलित करें। जब आप गैर-कार्यात्मक आवश्यकताओं में निर्दिष्ट प्रदर्शन प्राप्त करते हैं तो रोकें।

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

• कैशिंग: कैशिंग आपके वेब एप्लिकेशन को तेजी से महसूस करने, बैंडविड्थ को कम करने आदि के लिए तकनीकों में से एक है।

  1. सुनिश्चित करें कि आप क्लाइंट कैशिंग का उपयोग करते हैं (सर्वर-साइड कैशिंग आपके और ग्राहकों के बीच बैंडविड्थ का उपयोग कम नहीं करेगा), यह देखते हुए कि HTTP हेडर को ठीक से सेट करना अक्सर मुश्किल होता है।

  2. सुनिश्चित करें कि आप सही तरीके से यह निर्धारित करते हैं कि कैश को कितनी देर तक और कब इसे अमान्य करना है: यदि उत्पाद का विवरण 10 सेकंड पहले बदल गया, लेकिन एक ई-कॉमर्स वेबसाइट के ग्राहक अभी भी पुराने संस्करण को देखते हैं, तो यह ठीक है। यदि स्वामी ने विवरण बदल दिया, तो इसे सबमिट कर दिया, और अभी भी कैशिंग के कारण पिछले संस्करण को देखता है, यह समस्याग्रस्त है।

  3. केवल कैशिंग पर ध्यान केंद्रित न करें। उदाहरण के लिए, न्यूनतमकरण भी महत्वपूर्ण है। अनुरोधों की संख्या कम करना भी फायदेमंद हो सकता है।

Comments

+1 मैंने इस बारे में थोड़ा संकोच किया कि मुझे कैशिंग का उल्लेख करना चाहिए या नहीं और अंत में इसके खिलाफ निर्णय लेना चाहिए। अभी भी इसे लाने के लायक है, अच्छी बात है।

— जेएनएसजी

Answer 2

एक तीसरा विकल्प है जो आपने नहीं देखा होगा: क्रॉस ओरिजिनल रिसोर्स शेयरिंग (कॉर्स) ।

CORS मानक नए HTTP हेडर जोड़कर काम करता है जो सर्वरों को अनुमति देने के लिए अनुमति देता है मूल डोमेन के लिए संसाधन। ब्राउज़र इन हेडर का समर्थन करते हैं और उनके द्वारा लगाए गए प्रतिबंधों का सम्मान करते हैं।

उदाहरण : मान लें कि आपकी साइट http://my-cool-site.com है और, आपके पास डोमेन http://third-party-site.com पर एक तृतीय पक्ष एपीआई है , जिसे आप AJAX के माध्यम से एक्सेस कर सकते हैं।

और चलिए मान लेते हैं कि my-cool-site.com से आप जिस पेज को सर्वर करते हैं, उसने third-party-site.com से अनुरोध किया है। आम तौर पर, उपयोगकर्ता ब्राउज़र समान-मूल सुरक्षा नीति के अनुसार अपने स्वयं के डोमेन / उपडोमेन के अलावा किसी अन्य साइट पर AJAX कॉल को अस्वीकार कर देगा । लेकिन अगर ब्राउज़र और थर्ड पार्टी सर्वर CORS को सपोर्ट करते हैं, तो निम्न चीजें होती हैं:

• ब्राउज़र निम्नलिखित HTTP हेडर को third-party-site.com पर भेजेगा

  Origin: http://my-cool-site.com

• यदि तृतीय पक्ष सर्वर आपके डोमेन से अनुरोध स्वीकार करता है, तो वह निम्नलिखित HTTP हेडर के साथ प्रतिक्रिया देगा:

  Access-Control-Allow-Origin: http://my-cool-site.com

• सभी डोमेन को अनुमति देने के लिए, थर्ड पार्टी सर्वर इस हेडर को भेज सकता है:

  Access-Control-Allow-Origin: *

• यदि आपकी साइट को अनुमति नहीं है, तो ब्राउज़र एक त्रुटि फेंक देगा।

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

मुझे CORS पर एक अच्छा स्पष्टीकरण मिला , जिस पर आपको ऐसा करने का एक और तरीका भी मिलेगा: JSONP । लेकिन JSONP को आपके कोड में उचित मात्रा में परिवर्तन की आवश्यकता होगी।

एक CORS अनुरोध करने के लिए आप बस XMLHttpRequestफ़ायरफ़ॉक्स 3.5+, सफारी 4+ और क्रोम और XDomainRequestIE8 + में ऑब्जेक्ट का उपयोग करें। XMLHttpRequestऑब्जेक्ट का उपयोग करते समय , यदि ब्राउज़र देखता है कि आप एक क्रॉस-डोमेन अनुरोध करने की कोशिश कर रहे हैं, तो यह मूल रूप से CORS व्यवहार को ट्रिगर करेगा।

यहाँ एक जावास्क्रिप्ट फ़ंक्शन है जो आपको एक क्रॉस ब्राउज़र CORS ऑब्जेक्ट बनाने में मदद करता है।

function createCORSRequest(method, url){
    var xhr = new XMLHttpRequest();
    if ("withCredentials" in xhr){
        // XHR has 'withCredentials' property only if it supports CORS
        xhr.open(method, url, true);
    } else if (typeof XDomainRequest != "undefined"){ // if IE use XDR
        xhr = new XDomainRequest();
        xhr.open(method, url);
    } else {
        xhr = null;
    }
    return xhr;
}

चूंकि आप कहते हैं कि "अधिकांश ब्राउज़रों ने क्रॉस-डोमेन एक्सएमएल उपयोग बंद कर दिया है", मुझे लगता है कि आपका तीसरा पक्ष सर्वर कोर का समर्थन नहीं कर सकता है। फिर आपको वैकल्पिक दृष्टिकोण ढूंढना होगा।

---

Comments

क्या आप लिंक में मौजूद सामग्री को आज़मा कर देख सकते हैं? लिंक लिंक-सड़ने के लिए प्रवण हैं और एसई पर जानकारी देने का सबसे अच्छा तरीका नहीं हैं :)

— Ampt

अफसोस कि तीसरा पक्ष सर्वर कोर का समर्थन नहीं करता है।

— अमेथिस्ट्रैगन

Answer 3

स्केलेबिलिटी कारणों से मैं सर्वर का लोड यथासंभव कम रखना चाहूंगा

मुझे लगता है कि यह कमोबेश उत्तर की ओर इशारा करता है। ग्राहक को प्रीप्रोसेड डेटा देना या न देना मुख्य रूप से इस पर निर्भर करता है:

1. यातायात के संबंध में अंतर
2. प्रसंस्करण का प्रदर्शन प्रभाव
3. क्लाइंट पर एक अलग डेटा प्रारूप का प्रभाव

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

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

अंत में, सर्वर को स्केल करना आसान है, इससे क्लाइंट / ब्राउज़र या उपलब्ध बैंडविड्थ को स्केल करना है। इसे एक वाक्य में डालने के लिए, यह निर्भर करता है कि सिस्टम में अड़चन कहां है।

Comments

+1, और जोड़ना - विभिन्न स्थितियों में प्रदर्शन का परीक्षण करें।

— SeraM

Answer 4

मेरी पसंद कैश और कंप्रेस (अनावश्यक जानकारी दूर फेंकना) और क्लाइंट ब्राउज़र, आपके विकल्प # 2 पर gzip परिणाम देना होगा । क्योंकि आमतौर पर ब्राउजर हाई-एंड सीपीयू नहीं होते हैं और ब्राउजर नेटवर्क लाइनों का सर्वर सीमित क्षमता का होता है। मैं मोबाइल ग्राहकों के बारे में बात कर रहा हूँ । यदि आप मोबाइल ग्राहकों का समर्थन करने की योजना नहीं बनाते हैं, तो जो कुछ सरल है, उसे चुनेंGoogle:CORS proxy