इस दस्तावेज़ में बताया गया है कि Google Data API किस प्रोटोकॉल का इस्तेमाल करता है. साथ ही, इसमें क्वेरी के दिखने के तरीके, नतीजों जैसे दिखते हैं वगैरह की जानकारी भी शामिल होती है.
Google Data API के बारे में ज़्यादा जानकारी के लिए, Google Data Developer की गाइड दस्तावेज़ और प्रोटोकॉल गाइड देखें.
दर्शक
यह दस्तावेज़ उन सभी लोगों के लिए है जिन्हें Google डेटा एपीआई में इस्तेमाल किए गए एक्सएमएल फ़ॉर्मैट और प्रोटोकॉल की जानकारी चाहिए.
अगर आपको सिर्फ़ Google Data Client API का इस्तेमाल करने वाला कोड लिखना है, तो आपको इन जानकारी को जानने की ज़रूरत नहीं है. इसके बजाय, भाषा के हिसाब से क्लाइंट लाइब्रेरी का इस्तेमाल किया जा सकता है.
हालांकि, अगर आपको प्रोटोकॉल को समझना है, तो यह दस्तावेज़ पढ़ें. उदाहरण के लिए, हो सकता है कि आप यह दस्तावेज़ पढ़ना चाहें, ताकि आप नीचे दिए गए किसी भी काम में मदद पा सकें:
- Google डेटा आर्किटेक्चर का आकलन करना
- दी गई Google डेटा क्लाइंट लाइब्रेरी का इस्तेमाल किए बिना, प्रोटोकॉल का इस्तेमाल करके कोडिंग करना
- नई भाषा में क्लाइंट लाइब्रेरी लिखना
इस दस्तावेज़ में यह माना गया है कि आप एक्सएमएल, नेमस्पेस, सिंडिकेट किए गए फ़ीड, और एचटीटीपी में मौजूद GET, POST, PUT, और DELETE अनुरोधों के साथ-साथ एचटीटीपी के "रिसॉर्स" का सिद्धांत समझते हैं. उन चीज़ों के बारे में ज़्यादा जानकारी के लिए, इस दस्तावेज़ का अतिरिक्त संसाधन सेक्शन देखें.
यह दस्तावेज़ किसी खास प्रोग्रामिंग भाषा पर निर्भर नहीं है; आप ऐसी किसी भी प्रोग्रामिंग भाषा का इस्तेमाल करके Google डेटा मैसेज भेज और पा सकते हैं जो आपको HTTP अनुरोध जारी करने और XML-आधारित जवाबों को पार्स करने की अनुमति देती है.
प्रोटोकॉल की जानकारी
इस सेक्शन में, Google डेटा दस्तावेज़ का फ़ॉर्मैट और क्वेरी सिंटैक्स की जानकारी दी गई है.
दस्तावेज़ का फ़ॉर्मैट
Google डेटा, ऐटम, और आरएसएस 2.0 सभी का बुनियादी डेटा मॉडल एक ही है: ऐसा कंटेनर जिसमें दुनिया भर का कुछ डेटा और कितनी भी एंट्री मौजूद होती हैं. हर प्रोटोकॉल के लिए, फ़ॉर्मैट को किसी बेस स्कीमा से तय किया जाता है. हालांकि, इसे विदेशी नेमस्पेस का इस्तेमाल करके बढ़ाया जा सकता है.
Google डेटा एपीआई, ऐटम सिंडिकेशन फ़ॉर्मैट (रीड और लिखने, दोनों के लिए) या आरएसएस फ़ॉर्मैट (सिर्फ़ रीड के लिए) का इस्तेमाल कर सकता है.
ऐटम, Google डेटा का डिफ़ॉल्ट फ़ॉर्मैट है. आरएसएस फ़ॉर्मैट में जवाब का अनुरोध करने के लिए, /alt=rss/ पैरामीटर का इस्तेमाल करें. ज़्यादा जानकारी के लिए, क्वेरी अनुरोध देखें.
जब आरएसएस फ़ॉर्मैट में डेटा का अनुरोध किया जाता है, तो Google Data, आरएसएस फ़ॉर्मैट में फ़ीड (या रिसॉर्स का कोई और वर्शन) उपलब्ध कराता है. अगर किसी Google डेटा प्रॉपर्टी के लिए कोई आरएसएस प्रॉपर्टी मौजूद नहीं है, तो Google डेटा, ऐटम प्रॉपर्टी का इस्तेमाल करता है. यह दिखाने के लिए कि प्रॉपर्टी आरएसएस के दायरे में आती है, इसे सही नेमस्पेस के साथ लेबल किया जाता है.
ध्यान दें: ऐटम फ़ॉर्मैट में, ज़्यादातर Google डेटा फ़ीड, फ़ीड एलिमेंट पर xmlns एट्रिब्यूट तय करके, ऐटम नेमस्पेस को डिफ़ॉल्ट नेमस्पेस के तौर पर इस्तेमाल करते हैं. ऐसा करने के तरीके जानने के लिए, उदाहरण वाले सेक्शन में जाएं. इसलिए, इस दस्तावेज़ में दिए गए उदाहरणों में, ऐटम-फ़ॉर्मैट फ़ीड में मौजूद एलिमेंट के लिए साफ़ तौर पर atom: नहीं बताया गया है.
नीचे दी गई टेबल, ऐटम और आरएसएस को स्कीमा के एलिमेंट को दिखाने का तरीका बताती हैं. इन टेबल में नहीं बताए गए सभी डेटा को सादे एक्सएमएल के तौर पर देखा जाता है. साथ ही, यह डेटा, दोनों प्रज़ेंटेशन में एक जैसा दिखता है. जब तक कोई और सुझाव न दिया जाए, किसी दिए गए कॉलम में मौजूद एक्सएमएल एलिमेंट, उस कॉलम से जुड़े नेमस्पेस में होते हैं. इस खास जानकारी में स्टैंडर्ड XPath नोटेशन का इस्तेमाल होता है. खास तौर पर, स्लैश एलिमेंट की हैरारकी को दिखाता है और @ चिह्न किसी एलिमेंट के एट्रिब्यूट को दिखाता है.
नीचे दी गई हर टेबल में, हाइलाइट किए गए आइटम डालने ज़रूरी हैं.
नीचे दी गई टेबल में, Google डेटा फ़ीड के एलिमेंट दिखते हैं:
| फ़ीड स्कीमा आइटम | एटम रिप्रज़ेंटेशन | आरएसएस रिप्रज़ेंटेशन |
|---|---|---|
| फ़ीड का शीर्षक | /feed/title |
/rss/channel/title |
| फ़ीड ID | /feed/id |
/rss/channel/atom:id |
| फ़ीड HTML लिंक | /feed/link[@rel="alternate"]\[@type="text/html"]/@href |
/rss/channel/link |
| फ़ीड का ब्यौरा | /feed/subtitle |
/rss/channel/description |
| फ़ीड के लिए भाषा | /feed/@xml:lang |
/rss/channel/language |
| फ़ीड कॉपीराइट | /feed/rights |
/rss/channel/copyright |
| फ़ीड लेखक |
(कुछ मामलों में ज़रूरी; ऐटम की खास जानकारी देखें.) |
/rss/channel/managingEditor |
| फ़ीड के आखिरी बार अपडेट होने की तारीख | /feed/updated(आरएफ़सी 3339 फ़ॉर्मैट) |
/rss/channel/lastBuildDate(आरएफ़सी 822 फ़ॉर्मैट) |
| फ़ीड की श्रेणी | /feed/category/@term |
/rss/channel/category |
| फ़ीड श्रेणी स्कीम | /feed/category/@scheme |
/rss/channel/category/@domain |
| फ़ीड जनरेटर | /feed/generator/feed/generator/@uri |
/rss/channel/generator |
| फ़ीड का आइकॉन | /feed/icon |
/rss/channel/image/url (अगर लोगो भी न हो, तो उस मामले में फ़ीड में आइकॉन शामिल नहीं होगा) |
| फ़ीड का लोगो | /feed/logo |
/rss/channel/image/url |
नीचे दी गई टेबल में, Google डेटा के खोज नतीजों के फ़ीड के एलिमेंट दिखते हैं. ध्यान दें कि Google डेटा अपने खोज-नतीजे फ़ीड में कुछ OpenSearch 1.1 रिस्पॉन्स एलिमेंट दिखाता है.
| खोज के नतीजों के फ़ीड का स्कीमा आइटम | एटम रिप्रज़ेंटेशन | आरएसएस/ओपनसर्च रिप्रज़ेंटेशन |
|---|---|---|
| खोज के नतीजों की संख्या | /feed/openSearch:totalResults |
/rss/channel/openSearch:totalResults |
| खोज के नतीजों के शुरू होने का इंडेक्स | /feed/openSearch:startIndex |
/rss/channel/openSearch:startIndex |
| प्रति पेज खोज परिणामों की संख्या | /feed/openSearch:itemsPerPage |
/rss/channel/openSearch:itemsPerPage |
नीचे दी गई टेबल में, Google डेटा एंट्री के एलिमेंट दिखाए गए हैं:
| एंट्री आइटम के लिए स्कीमा | एटम रिप्रज़ेंटेशन | आरएसएस रिप्रज़ेंटेशन |
|---|---|---|
| एंट्री आईडी | /feed/entry/id |
/rss/channel/item/guid |
| एंट्री वर्शन आईडी | वैकल्पिक रूप से, EditURI में एम्बेड किया गया यह दस्तावेज़ देखें. इस दस्तावेज़ का ऑप्टिमाइज़िक कॉनकरेंसी सेक्शन देखें. | — |
| एंट्री टाइटल | /feed/entry/title |
/rss/channel/item/title |
| एंट्री लिंक | /feed/entry/link |
/rss/channel/item/link/rss/channel/item/enclosure/rss/channel/item/comments |
| एंट्री की खास जानकारी |
(कुछ मामलों में ज़रूरी; ऐटम की खास जानकारी देखें.) |
/rss/channel/item/atom:summary |
| एंट्री कॉन्टेंट |
(अगर कोई कॉन्टेंट एलिमेंट नहीं है, तो एंट्री में कम से कम एक |
/rss/channel/item/description |
| एंट्री ऑथर |
(कुछ मामलों में ज़रूरी; ऐटम की खास जानकारी देखें.) |
/rss/channel/item/author |
| एंट्री कैटगरी | /feed/entry/category/@term |
/rss/channel/item/category |
| एंट्री कैटगरी स्कीम | /feed/entry/category/@scheme |
/rss/channel/item/category/@domain |
| एंट्री पब्लिकेशन की तारीख | /feed/entry/published(आरएफ़सी 3339) |
/rss/channel/item/pubDate(आरएफ़सी 822) |
| एंट्री अपडेट होने की तारीख | /feed/entry/updated(आरएफ़सी 3339) |
/rss/channel/item/atom:updated(आरएफ़सी 3339) |
क्वेरी
इस सेक्शन में, क्वेरी सिस्टम को इस्तेमाल करने का तरीका बताया गया है.
क्वेरी मॉडल डिज़ाइन टेनेट
क्वेरी मॉडल को समझना बहुत आसान है. बुनियादी सिद्धांत हैं:
- क्वेरी को एचटीटीपी हेडर या पेलोड के हिस्से के तौर पर दिखाने के बजाय एचटीटीपी यूआरआई के तौर पर दिखाया जाता है. इस तरीके का एक फ़ायदा यह है कि आप किसी क्वेरी से लिंक कर सकते हैं.
- प्रेडिकेट का दायरा सिर्फ़ एक आइटम होता है. इस तरह, आपसी संबंध की क्वेरी भेजने का कोई तरीका नहीं है, जैसे कि "आज मुझे कम से कम 10 ईमेल भेजने वाले लोगों के सभी ईमेल ढूंढें."
- जिन प्रॉपर्टी पर क्वेरी के नतीजे दिखाए जा सकते हैं उनका सेट बहुत सीमित है. ज़्यादातर क्वेरी, टेक्स्ट सर्च में आसानी से दिखती हैं.
- नतीजे क्रम में लगाए जाते हैं.
- प्रोटोकॉल सामान्य तौर पर एक्सटेंसिबल होता है. अगर आपको अपनी सेवा में, अतिरिक्त नियमों या नियमों को बिना अनुमति के सार्वजनिक करना है, तो नए पैरामीटर की मदद से ऐसा आसानी से किया जा सकता है.
क्वेरी के अनुरोध
कोई क्लाइंट, एचटीटीपी डेटा के लिए GET अनुरोध जारी करके, Google के डेटा सेवा के बारे में क्वेरी करता है. क्वेरी यूआरआई में संसाधन का यूआरआई (ऐटम में FeedURI कहा जाता है) और उसके बाद क्वेरी पैरामीटर शामिल होते हैं. ज़्यादातर क्वेरी पैरामीटर, परंपरागत ?name=value[&...] यूआरएल पैरामीटर के तौर पर दिखाए जाते हैं. कैटगरी पैरामीटर अलग-अलग तरीके से मैनेज किए जाते हैं. इन्हें नीचे देखें.
उदाहरण के लिए, अगर FeedURI http://www.example.com/feeds/jo है, तो आप नीचे दिए गए यूआरआई के साथ क्वेरी भेज सकते हैं:
http://www.example.com/feeds/jo?q=Darcy&updated-min=2005-04-19T15:30:00Z
Google की डेटा सेवाएं, एचटीटीपी की शर्तों GET के साथ काम करती हैं. वे पिछली बार बदले गए रिस्पॉन्स के हेडर को, दिखाए गए फ़ीड या एंट्री में <atom:updated> एलिमेंट की वैल्यू के आधार पर सेट करते हैं. अगर कॉन्टेंट बदला नहीं गया है, तो कॉन्टेंट को वापस लाने से रोकने के लिए, क्लाइंट इस वैल्यू को If-Modified-Since अनुरोध हेडर की वैल्यू के तौर पर वापस भेज सकता है. अगर कॉन्टेंट, If-Modified-Since समय से नहीं बदला गया है, तो Google डेटा सेवा, 304 (बदलाव नहीं किया गया) एचटीटीपी रिस्पॉन्स दिखाती है.
Google डेटा सेवा के लिए श्रेणी क्वेरी और alt क्वेरी का इस्तेमाल करना ज़रूरी है; दूसरे पैरामीटर के लिए मदद ज़रूरी नहीं है. किसी स्टैंडर्ड पैरामीटर को पास करने से, दी गई सेवा से मिला रिस्पॉन्स 403 Forbidden रिस्पॉन्स में नहीं मिलता. काम न करने वाले स्टैंडर्ड पैरामीटर को पास करने से 400 Bad Request रिस्पॉन्स मिलता है. दूसरे स्टेटस कोड के बारे में जानकारी पाने के लिए, इस दस्तावेज़ का एचटीटीपी स्टेटस कोड सेक्शन देखें.
नीचे दिए गए टेबल में, स्टैंडर्ड क्वेरी पैरामीटर की खास जानकारी दी गई है. सभी पैरामीटर वैल्यू, यूआरएल के लिए कोड में बदली गई होनी चाहिए.
| पैरामीटर | मतलब | नोट |
|---|---|---|
q |
पूरे टेक्स्ट वाली क्वेरी स्ट्रिंग |
|
/-/category |
श्रेणी फ़िल्टर |
|
category |
श्रेणी फ़िल्टर |
|
author |
एंट्री लेखक |
|
alt |
वैकल्पिक प्रतिनिधित्व प्रकार |
|
updated-min, updated-max |
एंट्री अपडेट करने की तारीख पर सीमाएं |
|
published-min, published-max |
एंट्री प्रकाशन की तारीख पर सीमाएं |
|
start-index |
पहले नतीजे का 1-आधारित इंडेक्स वापस लाया जा सकता है |
|
max-results |
वापस लाए जाने वाले नतीजों की ज़्यादा से ज़्यादा संख्या | अगर किसी फ़ीड में डिफ़ॉल्ट फ़ीड max-results (डिफ़ॉल्ट फ़ीड साइज़ को सीमित करना) है, तो उसके लिए बहुत बड़ी संख्या में फ़ीड उपलब्ध कराया जा सकता है. |
| enterID | वापस मिलने वाली किसी खास एंट्री का आईडी |
|
कैटगरी से जुड़ी क्वेरी के बारे में जानकारी
हमने कैटगरी की क्वेरी के लिए, कुछ अलग फ़ॉर्मैट इस्तेमाल करने का फ़ैसला किया है. इस तरह की क्वेरी के बजाय:
http://example.com/jo?category=Fritz&category=2006
हम इनका इस्तेमाल करते हैं:
http://example.com/jo/-/Fritz/2006
यह तरीका, क्वेरी पैरामीटर का इस्तेमाल किए बिना संसाधन की पहचान करता है. साथ ही, यह क्लीनर यूआरआई बनाता है. हमने कैटगरी के लिए यह तरीका चुना, क्योंकि हमें लगता है कि कैटगरी की क्वेरी सबसे सामान्य क्वेरी होंगी.
इस तरीके का इस्तेमाल करने पर, आपको /-/ कैटगरी वाली क्वेरी के तौर पर इस्तेमाल करना होगा. इससे, Google की डेटा सेवाएं, कैटगरी क्वेरी में अंतर कर सकेंगी. जैसे, http://example.com/jo/MyPost/comments.
क्वेरी के जवाब
क्वेरी में अनुरोध पैरामीटर के आधार पर, ऐटम फ़ीड, ऐटम एंट्री या आरएसएस फ़ीड होता है.
क्वेरी के नतीजों में सीधे तौर पर <feed> एलिमेंट या <channel> एलिमेंट के नीचे, OpenSearch के ये एलिमेंट शामिल होते हैं (यह इस बात पर निर्भर करता है कि नतीजे ऐटम या आरएसएस वाले हैं या नहीं):
openSearch:totalResults- क्वेरी के लिए खोज के नतीजों की कुल संख्या (ज़रूरी नहीं है कि सभी नतीजों के फ़ीड में मौजूद हों).
openSearch:startIndex- पहले नतीजे का 1-आधारित इंडेक्स.
openSearch:itemsPerPage- एक पेज पर दिखने वाले आइटम की ज़्यादा से ज़्यादा संख्या. इससे क्लाइंट बाद के पेजों के किसी भी सेट के लिए डायरेक्ट लिंक जनरेट कर सकता है. हालांकि, इस नंबर का इस्तेमाल करने में कोई गड़बड़ी होने पर, क्वेरी का अनुरोध सेक्शन में मौजूद टेबल में,
start-indexसे जुड़ा नोट देखें.
एटम प्रतिक्रिया फ़ीड और एंट्री में नीचे दिए गए एटम और Google डेटा एलिमेंट के साथ-साथ ऐटम की खास जानकारी में शामिल दूसरे एलिमेंट भी शामिल हो सकते हैं:
<link rel="http://schemas.google.com/g/2005#feed" type="application/atom+xml" href="..."/>- उस यूआरआई को बताता है जहां पूरा ऐटम फ़ीड वापस पाया जा सकता है.
<link rel="http://schemas.google.com/g/2005#post" type="application/atom+xml" href="..."/>- ऐटम फ़ीड की PostURI के बारे में बताता है (जहां नई एंट्री पोस्ट की जा सकती हैं).
<link rel="self" type="..." href="..."/>- इस संसाधन का यूआरआई है.
typeएट्रिब्यूट की वैल्यू, अनुरोध किए गए फ़ॉर्मैट के हिसाब से तय होती है. अगर इस बीच कोई डेटा नहीं बदलता है, तो इस यूआरआई पर एक और जीईटी भेजने पर भी यही जवाब मिलेगा. <link rel="previous" type="application/atom+xml" href="..."/>- इस क्वेरी के नतीजे के सेट के पिछले हिस्से का यूआरआई बताता है, अगर उसे अलग किया जाता है.
<link rel="next" type="application/atom+xml" href="..."/>- इस क्वेरी के नतीजे के सेट के अगले हिस्से का यूआरआई बताता है, अगर इसे अलग किया गया हो.
<link rel="edit" type="application/atom+xml" href="..."/>- ऐटम एंट्री के EditURI के बारे में बताता है (जहां आप अपडेट की गई एंट्री भेजते हैं).
यहां खोज क्वेरी के जवाब में एक नमूना जवाब दिया गया है:
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:openSearch="http://a9.com/-/spec/opensearchrss/1.0/">
<id>http://www.example.com/feed/1234.1/posts/full</id>
<updated>2005-09-16T00:42:06Z</updated>
<title type="text">Books and Romance with Jo and Liz</title>
<link rel="alternate" type="text/html" href="http://www.example.net/"/>
<link rel="http://schemas.google.com/g/2005#feed"
type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full"/>
<link rel="http://schemas.google.com/g/2005#post"
type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full"/>
<link rel="self" type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full"/>
<author>
<name>Elizabeth Bennet</name>
<email>liz@gmail.com</email>
</author>
<generator version="1.0"
uri="http://www.example.com">Example Generator Engine</generator>
<openSearch:totalResults>2</openSearch:totalResults>
<openSearch:startIndex>0</openSearch:startIndex>
<entry>
<id>http://www.example.com/feed/1234.1/posts/full/4521614025009481151</id>
<published>2005-01-09T08:00:00Z</published>
<updated>2005-01-09T08:00:00Z</updated>
<category scheme="http://www.example.com/type" term="blog.post"/>
<title type="text">This is the title of entry 1009</title>
<content type="xhtml">
<div
xmlns="http://www.w3.org/1999/xhtml">This is the entry body of entry 1009</div>
</content>
<link rel="alternate" type="text/html"
href="http://www.example.com/posturl"/>
<link rel="edit" type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full/4521614025009481151"/>
<author>
<name>Elizabeth Bennet</name>
<email>liz@gmail.com</email>
</author>
</entry>
<entry>
<id>http://www.example.com/feed/1234.1/posts/full/3067545004648931569</id>
<published>2005-01-07T08:00:00Z</published>
<updated>2005-01-07T08:02:00Z</updated>
<category scheme="http://www.example.com/type" term="blog.post"/>
<title type="text">This is the title of entry 1007</title>
<content type="xhtml">
<div
xmlns="http://www.w3.org/1999/xhtml">This is the entry body of entry 1007</div>
</content>
<link rel="alternate" type="text/html"
href="http://www.example.com/posturl"/>
<link rel="edit" type="application/atom+xml"
href="http://www.example.com/feed/1234.1/posts/full/3067545004648931569"/>
<author>
<name>Elizabeth Bennet</name>
<email>liz@gmail.com</email>
</author>
</entry>
</feed>
अगर अनुरोध किया गया फ़ीड ऐटम फ़ॉर्मैट में है, तो क्वेरी का कोई पैरामीटर नहीं दिया गया है और नतीजे में सभी एंट्री मौजूद नहीं हैं, तो टॉप-लेवल फ़ीड में यह एलिमेंट शामिल किया जाता है: <link rel="next" type="application/atom+xml" href="..."/>. यह उस फ़ीड की ओर इशारा करता है जिसमें एंट्री का अगला सेट होता है. बाद के सेट में एक <link rel="previous" type="application/atom+xml" href="..."/> एलिमेंट शामिल होता है. सभी आगे बढ़ें लिंक पर क्लिक करने से, क्लाइंट को फ़ीड से सभी एंट्री मिल सकती हैं.
एचटीटीपी स्टेटस कोड
नीचे दी गई टेबल से पता चलता है कि Google की डेटा सेवाओं के हिसाब से, एचटीटीपी स्टेटस कोड का क्या मतलब है.
| कोड | इसका मतलब है |
|---|---|
| 200 ठीक | कोई गड़बड़ी नहीं. |
| 201 बनाया गया | संसाधन बनाया गया. |
| 304 संशोधित नहीं | रिसॉर्स, अनुरोध के If-Modified-Since हेडर में बताए गए समय के बाद से नहीं बदला है. |
| 400 खराब अनुरोध | अमान्य अनुरोध यूआरआई या शीर्षलेख, या असमर्थित गैर-मानक पैरामीटर. |
| 401 अनधिकृत | स्वीकृति चाहिए। |
| 403 अनुमति नहीं है | असमर्थित मानक पैरामीटर, प्रमाणीकरण या प्रमाणीकरण विफल. |
| 404 नहीं मिला | संसाधन (जैसे कि फ़ीड या एंट्री) नहीं मिला. |
| 409 टकराव | दिया गया वर्शन नंबर, संसाधन के नए वर्शन नंबर से मेल नहीं खाता. |
| 500 सर्वर में गड़बड़ी | कोई अंदरूनी गड़बड़ी हुई. यह डिफ़ॉल्ट कोड है, जिसका उपयोग सभी अज्ञात गड़बड़ियों के लिए किया जाता है. |
ऑप्टिक कॉनकरेंसी (वर्शन)
कभी-कभी यह पक्का करना ज़रूरी होता है कि कई क्लाइंट अनजाने में एक-दूसरे के बदलावों को ओवरराइट न कर दें. यह सबसे आसान काम यह पक्का करके किया जाता है कि क्लाइंट जिस एंट्री में बदलाव कर रहा है उसका मौजूदा वर्शन उसके वर्शन से मेल खाता है. अगर कोई दूसरा क्लाइंट, पहला क्लाइंट अपडेट करने से पहले अपडेट करता है, तो पहले क्लाइंट के अपडेट को अस्वीकार कर दिया जाएगा, क्योंकि पहले क्लाइंट में अब नए वर्शन पर आधारित बदलाव नहीं किए जा रहे हैं.
Google डेटा फ़ीड में, वर्शन का इस्तेमाल करने वाली फ़ीड में यह बदलाव किया जा सकता है. इसके लिए, हम हर एंट्री के EditURI में वर्शन का आईडी जोड़ते हैं. ध्यान दें कि सिर्फ़ शुरुआती बदलाव का असर एडिट्यूरी (यूआरआई) पर पड़ता है. इस स्कीम में, हर अपडेट एंट्री का एडिटयूआर बदलता है, जिससे यह गारंटी मिलती है कि ओरिजनल वर्शन के आधार पर बाद में अपडेट नहीं हो पाएंगे. हटाना, इस सुविधा के संबंध में अपडेट के समान है; अगर आप किसी पुरानी वर्शन संख्या के साथ हटाएं भेजते हैं, तो हटाया जाना विफल हो जाता है.
Google के सभी डेटा फ़ीड में, एक साथ काम करने की सुविधा का इस्तेमाल नहीं किया जा सकता. काम करने वाले किसी फ़ीड में, अगर सर्वर को PUT या DELETE पर एक वर्शन विरोध का पता चलता है, तो सर्वर 409 Conflict के साथ जवाब देता है. जवाब के मुख्य भाग में एंट्री की मौजूदा स्थिति (ऐटम एंट्री दस्तावेज़) होती है. क्लाइंट को सलाह दी जाती है कि वह 409 रिस्पॉन्स में मौजूद EditURI का इस्तेमाल करके, इस विवाद को सुलझाएं और अनुरोध को फिर से सबमिट करें.
प्रेरणा और डिज़ाइन नोट
शब्द को एक ही जगह पर सही तरीके से मैनेज करने से, हमें सिमेंटिक लागू करने में मदद मिलती है. इसके लिए, वर्शन आईडी के लिए नए मार्कअप की ज़रूरत नहीं होती. इससे, Google डेटा के रिस्पॉन्स, Google के ऐटम एंडपॉइंट के साथ काम करते हैं.
वर्शन आईडी बताने के बजाय, हम हर एंट्री (/atom:entry/atom:updated) पर अपडेट होने के टाइमस्टैंप को देखना चुन सकते थे. हालांकि, अपडेट टाइमस्टैंप का इस्तेमाल करने में दो समस्याएं हैं:
- यह सिर्फ़ अपडेट के लिए काम करता है, न कि मिटाने के लिए.
- यह ऐप्लिकेशन को वर्शन आईडी के तौर पर तारीख/समय की वैल्यू इस्तेमाल करने के लिए मजबूर करता है. इससे, मौजूदा डेटा स्टोर के ऊपर Google डेटा को फिर से लगाना मुश्किल हो जाता है.
पुष्टि करना
जब कोई क्लाइंट किसी सेवा को ऐक्सेस करने की कोशिश करता है, तो उसे सेवा के लिए उपयोगकर्ता के क्रेडेंशियल देने पड़ सकते हैं, ताकि यह दिखाया जा सके कि उपयोगकर्ता के पास कार्रवाई करने का अधिकार है.
पुष्टि करने के लिए, क्लाइंट को यह तरीका अपनाना चाहिए:
- डेस्कटॉप ऐप्लिकेशन को Google-विशिष्ट प्रमाणीकरण सिस्टम का उपयोग करना चाहिए, जिसे इंस्टॉल किए गए ऐप्लिकेशन के लिए खाता प्रमाणीकरण कहते हैं (जिसे "ClientLogin" भी कहा जाता है). (वेब-आधारित क्लाइंट को इस सिस्टम का उपयोग नहीं करना चाहिए.)
- वेब पर आधारित क्लाइंट, जैसे Google डेटा सेवा को तीसरे पक्ष का फ़्रंट एंड, वेब-आधारित ऐप्लिकेशन के लिए खाता पुष्टि प्रॉक्सी (जिसे "AuthSub" भी कहा जाता है) Google के खास पुष्टि करने वाले सिस्टम का इस्तेमाल करना चाहिए.
ClientLogin सिस्टम में, डेस्कटॉप क्लाइंट उपयोगकर्ता से उनके क्रेडेंशियल मांगता है और फिर उन क्रेडेंशियल को Google प्रमाणीकरण सिस्टम पर भेजता है.
अगर पुष्टि हो जाती है, तो पुष्टि करने वाला सिस्टम एक टोकन दिखाता है. क्लाइंट इसे बाद में Google के डेटा अनुरोधों को भेजते समय, एचटीटीपी ऑथराइज़ेशन हेडर में इस्तेमाल करता है.
अगर पुष्टि नहीं हो पाती है, तो सर्वर 403 ऐक्सेस का स्टेटस कोड दिखाता है. साथ ही, WWW- Authenticator हेडर भी दिखाता है. इसमें पुष्टि करने के लिए एक चैलेंज होता है.
AuthSub सिस्टम इसी तरह काम करता है, लेकिन बस उपयोगकर्ता से उसके क्रेडेंशियल मांगने के बजाय उपयोगकर्ता को ऐसी Google सेवा से कनेक्ट करता है जो क्रेडेंशियल का अनुरोध करती है. इसके बाद, इस सेवा को एक टोकन मिलता है, जिसका इस्तेमाल वेब ऐप्लिकेशन कर सकता है. इस तरीके का फ़ायदा यह है कि Google, वेब फ़्रंट एंड की जगह उपयोगकर्ता के क्रेडेंशियल को सुरक्षित तरीके से हैंडल और स्टोर करता है.
पुष्टि करने वाले इन सिस्टम के बारे में जानने के लिए, Google डेटा की पुष्टि करने से जुड़ी खास जानकारी या Google खाते की पुष्टि करना दस्तावेज़ देखें.
सेशन की स्थिति
कई कारोबारी नियम लागू करने के लिए सेशन को बनाए रखना ज़रूरी होता है—जैसे कि उपयोगकर्ता के सेशन की स्थिति को ट्रैक करना.
Google, सेशन की स्थिति को दो तरीकों से ट्रैक करता है: कुकी का इस्तेमाल करके और टोकन का इस्तेमाल करके, जिसे क्वेरी पैरामीटर के तौर पर भेजा जा सकता है. दोनों तरीकों से एक जैसा असर पड़ता है. हमारी सलाह है कि क्लाइंट इनमें से किसी एक सत्र-राज्य ट्रैकिंग पद्धति का समर्थन करें (या तो एक ही काफ़ी है). अगर कोई क्लाइंट इनमें से किसी भी तरीके का इस्तेमाल नहीं करता, तो वह क्लाइंट अब भी Google डेटा सेवाओं के साथ काम करेगा, लेकिन इन तरीकों का समर्थन करने वाले क्लाइंट की तुलना में परफ़ॉर्मेंस पर असर पड़ सकता है. खास तौर पर, अगर कोई क्लाइंट इन तरीकों का इस्तेमाल नहीं करता, तो हर अनुरोध के साथ दूसरे वेबलिंक पर भेजा जाता है. इसलिए, हर अनुरोध (और उससे जुड़े डेटा) को सर्वर पर दो बार भेजा जाता है. इससे क्लाइंट और सर्वर की परफ़ॉर्मेंस पर असर पड़ता है.
Google क्लाइंट लाइब्रेरी आपके लिए सेशन की स्थिति हैंडल करती है. इसलिए, अगर आप हमारी लाइब्रेरी का इस्तेमाल करते हैं, तो सेशन की स्थिति के बारे में सहायता पाने के लिए आपको कुछ करने की ज़रूरत नहीं है.
अतिरिक्त रिसॉर्स
आपको तीसरे पक्ष के ये दस्तावेज़ उपयोगी लग सकते हैं:
- इंटरटेशन की मदद से, ऐटम और आरएसएस की तुलना
- IBM से ऐटम की खास जानकारी
- आरएसएस के लिए, डबलिन कोर एक्सटेंशन
- एचटीटीपी 1.1 तरीका की परिभाषाएं;
GET,POST,PUT, औरDELETEकी जानकारी - एचटीटीपी 1.1 स्टेटस कोड की परिभाषाएं
- REST प्रोटोकॉल कैसे बनाएं
- वेब सेवाओं को बनाना बाकी बचे पैसे
- एक्सएमएल टेक्नोलॉजी का तकनीकी परिचय
- एक्सएमएल नेमस्पेस के उदाहरण