The Web is my API

Paul Kinlan
Available in: English (Original) Deutsch Español Français 日本語 русский язык tiếng Việt தமிழ் bahasa Indonesia

माइकल माहेमॉफ ने मुझे वेब की संभावनाओं के बारे में बहुत कुछ सिखाया। वेब पर निर्मित माइक के साथ काम करने से पहले और मुझे लिंकिबिलिटी और डिस्कवरी जैसे लाभों को समझ गया, लेकिन मुझे वास्तव में क्या संभव होगा इसकी पूरी तस्वीर नहीं मिली।

एक बात यह है कि माइक ने कहा था “वेब मेरा एपीआई है”, जहां उन्होंने माइक्रोफॉर्मेट्स और अन्य संरचित डेटा के माध्यम से एक पृष्ठ में अपनी साइट और डेटा को बेनकाब करने में सक्षम होने के बारे में बात की और सीधे इसे एक्सेस करने में सक्षम होने के बारे में बात की एक और XML ब्राउज़र संदर्भ, एक साधारण XMLHttpRequest और CORS API का उपयोग करके:

Anyway, what’s cool about this is you can treat the web as an API. The Web is my API. “Scraping a web page” may sound dirtier than “consuming a web service”, but it’s the cleaner approach in principle. A website sitting in your browser is a perfectly human-readable depiction of a resource your program can get hold of, so it’s an API that’s self-documenting. The best kind of API. But a whole HTML document is a lot to chew on, so we need to make sure it’s structured nicely, and that’s where microformats come in, gloriously defining lightweight standards for declaring info in your web page. There’s another HTML5 tie-in here, because we now have a similar concept in the standard, microdata.

यह लगभग उसी समय था जब मैं वेब इरादों पर काम करना शुरू कर रहा था, जिसकी भावना समान थी & mdash; उपयोगकर्ताओं को किसी अन्य मूल से डेटा और सेवाओं तक पहुंच प्रदान करें & mdash; लेकिन यह बहुत अधिक जटिल था। मैं सेवाओं की खोज को सक्षम करना चाहता था और फिर उन पृष्ठों से बातचीत करना चाहता था। और माइक डेटा और सेवाओं तक पहुंच प्रदान करने के लिए वेब को स्थानांतरित करना चाहता था। यह मेरे साथ अटक गया। यहां तक ​​कि अगर मैं मूल विशेषता भूल गया

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

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

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

हम ऐसी दुनिया में जा रहे हैं जहां क्लाइंट में साइट जेएस और सत्र के साथ उत्पन्न हो रही है और उपयोगकर्ता के लिए राज्य पूरी तरह से ग्राहक पर प्रबंधित किया जाता है।

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

प्रत्येक वेबसाइट एक एपीआई का पर्दाफाश करने में सक्षम होना चाहिए कि साइट के मालिक सीधे अन्य ग्राहकों के लिए नियंत्रण है।

अच्छी खबर यह है कि हम पहले से ही ऐसा कर सकते हैं, हमारे पास प्लेटफ़ॉर्म पर कम से कम 7 साल (पोस्टमेसेज 'और' संदेश चैनल ') के लिए प्राइमेटिव हैं, और हमेशा' window.open के बाद से, लेकिन हम इसका उपयोग नहीं करते हैं इन औजारों को इसी कारणों से साइटों के साथ बातचीत करने के लिए क्यों हम सीओआरएस का उपयोग नहीं करते हैं: यह कठिन है और एक सनी एपीआई को परिभाषित करना लगभग असंभव है जो उपयोग करने के लिए सरल और सुसंगत है और इसे प्रत्येक सेवा के लिए विशाल तृतीय पक्ष पुस्तकालयों में खींचने की आवश्यकता नहीं है कि आप के साथ बातचीत करना चाहते हैं।

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

हमारे पास एक पुस्तकालय है जो मदद करता है: कॉमलिंक

कॉमलिंक एक छोटा एपीआई है जो ‘संदेशChannelऔर' postMessage एपीआई को एक एपीआई में सारणीबद्ध करता है जो ऐसा लगता है कि आप स्थानीय संदर्भ में दूरस्थ कक्षाओं और कार्यों को तुरंत चालू कर रहे हैं। उदाहरण के लिए:

वेबसाइट

// Set up.
const worker = w.open('somesite');
const api = Comlink.proxy(w);

// Use the API.
const work = await new api.Test();
const str = await work.say('Yo!');
console.log(str);

** वेब वर्कर **

class Test {
  say() {
    return `Hi ${this.x++}, ${msg}`;
  }
}

// Expose the API to anyone who connects.
Comlink.expose({Test}, window);

हम सेवा पर एक एपीआई का पर्दाफाश करते हैं, हम क्लाइंट में प्रॉक्सी के माध्यम से एपीआई का उपभोग करते हैं।

क्या कोई बेहतर उदाहरण है?

मैंने एक साइट जो एक पबूबबबब एंडपॉइंट की सदस्यता लेती है और जब यह एक पिंग प्राप्त करती है तो यह एक JSON संदेश भेजती है उपयोगकर्ता परिभाषित एंडपॉइंट पर। मैं इस छोटे ऐप के लिए पुश अधिसूचना इंफ्रास्ट्रक्चर का प्रबंधन नहीं करना चाहता था, मैंने बनाई एक और साइट (webpush.rocks) यह सब कर सकती है, मैं बस उस सेवा के साथ एकीकृत करना चाहता हूं ..

लेकिन मैं webpush.rocks के क्लाइंट में मेरी साइट पर वापस सदस्यता URL (सूचनाओं का टुकड़ा मुझे नोटिफिकेशन भेजने में सक्षम होना चाहिए) कैसे प्राप्त करूं?

जब मैंने शुरुआत में इस साइट का निर्माण किया था, तो आप जो भी कर सकते थे, वह उपयोगकर्ता को साइट खोलने देता था और फिर पृष्ठों के बीच यूआरएल कॉपी और पेस्ट करता था। क्यों न सिर्फ एक एपीआई का खुलासा करें कि कोई भी साइट उपयोग कर सकती है? वही मैंने किया।

webpush.rocks ‘पुशमैनगर’ नामक एक एपीआई को परिभाषित करता है जिस पर ‘subscription आईडी’ पर एक ही विधि है। जब पृष्ठ लोड होता है तो यह विंडो को इस एपीआई को निम्नानुसार दिखाता है:

class PushManager {
  constructor() {
  }

  async subscriptionId() {
    //global var ick...
    let reg = await navigator.serviceWorker.getRegistration();
    let sub = await reg.pushManager.getSubscription();
    if(sub) {
        return `${location.origin}/send?id=${sub.endpoint}`;
    }
    else {
        return ``;
    }
  }
}

Comlink.expose({PushManager}, window);

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

कॉलिंग क्लाइंट साइट पर वापस (ऐप जो सदस्यता आईडी प्राप्त करना चाहता है)। जब कोई उपयोगकर्ता लिंक पर क्लिक करता है, तो हम उस खिड़की का संदर्भ प्राप्त करते हैं जिसे हमने अभी खोला है और हमारे ‘कॉमलिंक’ प्रॉक्सी को हुक-अप किया है। सेवा एपीआई अब हमारे क्लाइंट के सामने आ गई है और हम ‘पुशमैनगर’ एपीआई को तत्काल कर सकते हैं जैसे कि यह एक स्थानीय सेवा थी, लेकिन यह सभी अन्य विंडो में रिमोट इंस्टेंस सेवा के साथ बातचीत कर रहा है।

let endpointWindow = window.open('', 'endpointUrlWindow');

let pushAPI = Comlink.proxy(endpointWindow);
let pm = await new pushAPI.PushManager();
let id = await pm.subscriptionId();

// Update the UI.
endpointUrlEl.value = id;

क्या हो रहा है इसका एक बहुत तेज़ वीडियो यहां दिया गया है। एक बहुत ही सरल और हल्के वजन की बातचीत, यह सेवा खोलती है और उसके बाद आईडी की आवश्यकता होती है।

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

_ वेब एपीआई है ._

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

  • आप जो अच्छे हैं उस पर फ़ोकस करें।
  • साइटों और ऐप्स के बीच तेज़ डेटा स्थानांतरण क्योंकि यह सब क्लाइंट में है।
  • ऑफ़लाइन होने पर भी आईपीसी।
  • मूल संदर्भ में कोड चलाएं

साइट्स का क्या खुलासा होना चाहिए?

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

मैं ऐसी जगह पर जाना चाहूंगा जहां हर साइट उपयोगकर्ताओं के लिए एक सतत API का खुलासा कर सके और अन्य कार्यक्षमता और सेवाओं को खोजने का एक तरीका हो।

प्रत्येक साइट के मालिक अपनी सेवा के लिए केवल मूल कार्यक्षमता का पर्दाफाश कर सकते हैं ताकि हम सीआरयूडी आधारित संचालन कर सकें। हम जटिल बातचीत कर सकते हैं।

हम एक वेब पर जा सकते हैं जहां हमारे पास यूनिक्स जैसी सेवाएं हैं जो एक चीज अच्छी तरह से करती हैं और उपयोगकर्ता क्लाइंट पर उन्हें एक साथ पाइप करता है।

प्रत्येक साइट सेवा मालिक द्वारा परिभाषित पृष्ठ के एक उप-समूह का ‘VDOM`’ का खुलासा कर सकती है ताकि हमारे पास सुरक्षित रूप से साइटों के बीच DOM के आधार पर स्थानांतरित करने के लिए एक सतत तरीका हो।

मैं कल्पना कर सकता हूं कि हम पेज पर सभी schema.org आधारित ऑब्जेक्ट्स या अन्य संरचित डेटा तक त्वरित पहुंच चाहते हैं (जैसे गतिशील रूप से जेनरेट किया जा सकता है) जैसे माइक ने अपनी मूल पोस्ट में किया था।

कॉमलिंक हमें सालों से आसपास के मंच प्राइमेटिव्स के शीर्ष पर जल्दी और आसानी से सेवाओं का पर्दाफाश करने और उपभोग करने का एक तरीका प्रदान करता है। अंततः हमारे पास बहुत सारे टुकड़े हैं जो हमें वेब एपीआई बनाने की अनुमति देते हैं।

_ वेब मेरा एपीआई है। इसे भी बनाओ ._

Paul Kinlan

Trying to make the web and developers better.

RSS Github Medium