Ad Manager API के मौजूदा मेजर वर्शन के लिए, मेजर वर्शन की रिलीज़ और पुराने सिस्टम के साथ काम करने वाली इन-प्लेस रिलीज़, दोनों उपलब्ध हैं.
मेजर वर्शन (जैसे, v1) में, सेवाओं, तरीकों, और फ़ील्ड को किसी भी समय बंद किया जा सकता है. हालांकि, ये तब तक काम करते रहेंगे, जब तक उस मेजर वर्शन को बंद नहीं कर दिया जाता.
मेजर वर्शन की रिलीज़
मेजर वर्शन की रिलीज़ का मतलब है, ऐसी रिलीज़ जिसमें एपीआई में ऐसे बदलाव किए गए हों जो पुराने वर्शन के साथ काम नहीं करेंगे. इन रिलीज़ के नाम होंगे और इनके एपीआई एंडपॉइंट अलग-अलग होंगे. माइग्रेशन की अवधि के दौरान, पिछले मेजर वर्शन काम करते रहेंगे.
Ad Manager API के मेजर वर्शन की रिलीज़ की कोई तय अवधि नहीं होती. नए मेजर वर्शन सिर्फ़ तब रिलीज़ किए जाएंगे, जब इनकी ज़रूरत होगी.
इन-प्लेस रिलीज़
मौजूदा मेजर एपीआई वर्शन के लिए, पुराने सिस्टम के साथ काम करने वाले बदलावों को इन-प्लेस रिलीज़ किया जाता है. इनमें नई सुविधाएं और गड़बड़ियां ठीक करने वाले अपडेट शामिल होते हैं. क्लाइंट को एपीआई के जवाबों में मौजूद ऐसे फ़ील्ड को मैनेज करना होगा जिनके बारे में उन्हें जानकारी नहीं है.
पुराने सिस्टम के साथ काम करने की सुविधा
मेजर वर्शन में किए गए बदलावों के लिए, पुराने सिस्टम के साथ काम करने की सुविधा बनी रहती है. पुराने सिस्टम के साथ काम करने की सुविधा का मतलब है:
सोर्स के साथ काम करने की सुविधा: पिछले वर्शन के लिए लिखा गया कोड, नए वर्शन के साथ कंपाइल होता है. साथ ही, क्लाइंट लाइब्रेरी के नए वर्शन के साथ सही तरीके से काम करता है.
वायर के साथ काम करने की सुविधा: पिछले वर्शन के लिए लिखा गया कोड, नए सर्वर के साथ सही तरीके से कम्यूनिकेट करता है. दूसरे शब्दों में कहें, तो इनपुट और आउटपुट, दोनों ही एक-दूसरे के साथ काम करते हैं. साथ ही, सीरियलाइज़ेशन और डीसीरियलाइज़ेशन की उम्मीदें भी पूरी होती हैं.
सिमैंटिक के साथ काम करने की सुविधा: पिछले वर्शन के लिए लिखा गया कोड, डेवलपर की उम्मीद के मुताबिक काम करता है.
यहां दी गई टेबल में, एपीआई में किए गए बदलावों के टाइप और यह जानकारी दी गई है कि ये बदलाव पुराने सिस्टम के साथ काम करेंगे या नहीं.
सेवाएं
| बदलाव का टाइप | पुराने सिस्टम के साथ काम करने की सुविधा |
|---|---|
| नई सेवा जोड़ना | हां |
| कोई सेवा हटाना | नहीं |
तरीके
| बदलाव का टाइप | पुराने सिस्टम के साथ काम करने की सुविधा |
|---|---|
| कोई नया तरीका जोड़ना | हां |
| कोई तरीका हटाना | नहीं |
| किसी तरीके के अनुरोध या जवाब के टाइप में बदलाव करना | नहीं |
ऑब्जेक्ट
| बदलाव का टाइप | पुराने सिस्टम के साथ काम करने की सुविधा |
|---|---|
| कोई ज़रूरी फ़ील्ड जोड़ना | नहीं |
| कोई ऐसा फ़ील्ड जोड़ना जो ज़रूरी न हो | हां |
| किसी फ़ील्ड को सब-मैसेज में ले जाना या उससे बाहर ले जाना | नहीं |
| किसी फ़ील्ड को ज़रूरी से बदलकर, ऐसा फ़ील्ड बनाना जो ज़रूरी न हो | हां |
| किसी फ़ील्ड को ऐसा फ़ील्ड बनाना जो ज़रूरी न हो से बदलकर, ज़रूरी फ़ील्ड बनाना | नहीं |
| बदले नहीं जा सकने वाले किसी प्रतिबंध को हटाना | हां |
| बदले नहीं जा सकने वाला कोई प्रतिबंध जोड़ना | नहीं |
इन्यूमरेट
| बदलाव का टाइप | पुराने सिस्टम के साथ काम करने की सुविधा |
|---|---|
| कोई enum वैल्यू जोड़ना | हां |
| कोई enum वैल्यू हटाना | नहीं |
बंद किए गए फ़ील्ड का व्यवहार
बदले गए फ़ील्ड
जिन फ़ील्ड को बदला गया है उनके लिए, दोनों फ़ील्ड में वैल्यू भरी जाएंगी.
अपडेट करते समय, दोनों में से किसी भी फ़ील्ड को सेट किया जा सकता है. अपडेट के अनुरोध में, दोनों फ़ील्ड शामिल करने पर INVALID_ARGUMENT गड़बड़ी होती है.
यह स्कीमा देखें:
{
// The cost of this Foo in micros.
// Deprecated: Use `cost` instead.
"costMicros": number,
// The cost of this Foo.
"cost": {
object (Money)
}
}
पढ़ने के जवाब में, दोनों फ़ील्ड में एक जैसी वैल्यू भरी जाती हैं:
{
"costMicros": 1250000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 250000000
}
}
अपडेट के अनुरोध में, दोनों में से किसी भी वैल्यू को सेट किया जा सकता है. दोनों फ़ील्ड शामिल करने पर, INVALID_ARGUMENT गड़बड़ी होती है:
costMicros
// Update payload
{
"costMicros": 1500000
}
// Response payload
{
"costMicros": 1500000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
लागत
// Update payload
{
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
// Response payload
{
"costMicros": 1500000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
दोनों
// Update payload
{
"costMicros": 1250000,
"cost": {
"currencyCode": "USD",
"units": "1",
"nanos": 500000000
}
}
// Response payload
{
"error": {
"code": 400,
"message": "Request contains an invalid argument.",
"status": "INVALID_ARGUMENT",
"details": [
{
"@type": "type.googleapis.com/google.rpc.BadRequest",
"fieldViolations": [
{
"field": "costMicros",
"description": "Cannot update both costMicros and cost."
}
]
}
]
}
}
बंद की गई सुविधाएं
अगर किसी प्रॉडक्ट की कोई सुविधा बंद कर दी जाती है, तो उससे जुड़े फ़ील्ड को बंद के तौर पर मार्क किया जाएगा. साथ ही, हो सकता है कि वे सिमैंटिक के हिसाब से सही डिफ़ॉल्ट वैल्यू दिखाएं. अपडेट को अनदेखा किया जा सकता है.
{
// The salesperson split amount in micros.
// Deprecated: The Sales Management feature has been deprecated. This field
// will always be `0`.
"salespersonSplitMicros": number,
}