उपयोगकर्ता और ऐक्सेस मैनेजमेंट को माइग्रेट करना

Content API for Shopping में, Account संसाधन के किसी फ़ील्ड की मदद से, उपयोगकर्ताओं और उनके ऐक्सेस के अधिकारों को मैनेज किया जाता था. Merchant API में, इसकी जगह समर्पित संसाधन जिसका नाम है User और उससे जुड़े तरीके (बनाना, मिटाना, पाना, सूची बनाना, पाथ) इस्तेमाल किए जाते हैं. ज़्यादा जानकारी के लिए, देखें अपने खाते के ऐक्सेस को कंट्रोल करना.

मुख्य अंतर

Content API for Shopping की तुलना में, Merchant API से उपयोगकर्ता मैनेजमेंट के लिए ये फ़ायदे मिलते हैं:

  • खास संसाधन: इससे यह ज़्यादा आसानी से और सीधे तौर पर कंट्रोल किया जा सकता है कि आपके Merchant Center खाते को कौन ऐक्सेस कर सकता है और वे क्या-क्या कर सकते हैं.
  • RESTful संसाधन के नाम: Merchant API में, User संसाधनों की पहचान करने के लिए, संसाधन का पूरा नाम इस्तेमाल करें. जैसे, accounts/12345/users/example@example.com.
  • me एलियास: पुष्टि किए गए उपयोगकर्ता के बारे में बताने के लिए, संसाधन के नाम में ईमेल पते की जगह me एलियास का इस्तेमाल किया जा सकता है. जैसे, accounts/12345/users/me.
  • ऐक्सेस के अधिकारों को एक साथ दिखाना: Merchant API, Content API के बूलियन ऐक्सेस फ़ील्ड (उदाहरण के लिए, admin, reportingManager) को एक ही, बार-बार इस्तेमाल किए जा सकने वाले फ़ील्ड में दिखाता है.access_rights
  • उपयोगकर्ता को न्योता भेजना और उसकी पुष्टि करना: Merchant API में, उपयोगकर्ता की स्थिति (PENDING या VERIFIED) साफ़ तौर पर दिखती है. नया उपयोगकर्ता बनाने पर, वह PENDING स्थिति में तब तक रहता है, जब तक वह न्योता स्वीकार नहीं कर लेता. इससे, उपयोगकर्ता की स्थिति के बारे में एपीआई की जानकारी मिलती है. यह सुविधा, Content API for Shopping में उपलब्ध नहीं थी. ## अनुरोध जोड़ें

Merchant API, उपयोगकर्ताओं को मैनेज करने के लिए, अनुरोध के इन यूआरएल का इस्तेमाल करता है:

  • GET /accounts/v1/accounts/{account}/users/{email}
  • GET /accounts/v1/accounts/{account}/users
  • POST /accounts/v1/accounts/{account}/users
  • PATCH /accounts/v1/accounts/{account}/users/{email}
  • DELETE /accounts/v1/accounts/{account}/users/{email}

यहां दी गई टेबल में, Content API for Shopping और Merchant API के अनुरोध के यूआरएल की तुलना की गई है.

अनुरोध का ब्यौरा Content API for Shopping Merchant API
किसी खाते के उपयोगकर्ताओं की जानकारी पाना GET {api_version}/{merchantId}/accounts/{accountId} GET {api_version}/accounts/{account}/users
उपयोगकर्ता बनाना PATCH {api_version}/{merchantId}/accounts/{accountId} POST {api_version}/accounts/{account}/users
उपयोगकर्ता की जानकारी अपडेट करना PATCH {api_version}/{merchantId}/accounts/{accountId} PATCH {api_version}/accounts/{account}/users/{email}
उपयोगकर्ता को मिटाना PATCH {api_version}/{merchantId}/accounts/{accountId} DELETE {api_version}/accounts/{account}/users/{email}

आइडेंटिफ़ायर

यहां दी गई टेबल में, Content API for Shopping और Merchant API के अनुरोधों में इस्तेमाल किए गए आइडेंटिफ़ायर की तुलना की गई है.

आइडेंटिफ़ायर का ब्यौरा Content API for Shopping Merchant API
खाता आइडेंटिफ़ायर accountId accounts/{account} में मौजूद account
यूज़र आइडेंटिफ़ायर AccountUser ऑब्जेक्ट में मौजूद email_address accounts/{account}/users/{email} में मौजूद email

तरीके

यहां दी गई टेबल में, Content API for Shopping और Merchant API के तरीकों की तुलना की गई है.

Content API for Shopping Merchant API उपलब्धता और अहम जानकारी
accounts.update users.create इससे किसी खाते के लिए नया उपयोगकर्ता बनाया जाता है.
accounts.get users.get इससे किसी एक उपयोगकर्ता की जानकारी मिलती है.
accounts.get users.list इससे किसी खाते के सभी उपयोगकर्ताओं की सूची मिलती है.
accounts.update users.patch इससे किसी उपयोगकर्ता के ऐक्सेस के अधिकार अपडेट किए जाते हैं.
accounts.update users.delete इससे किसी खाते से उपयोगकर्ता को मिटाया जाता है.

फ़ील्ड में किए गए बदलावों की ज़्यादा जानकारी

फ़ील्ड के इस्तेमाल को इस तरह अपडेट करें:

Content API for Shopping Merchant API ब्यौरा
users (बार-बार इस्तेमाल किया गया AccountUser) users (बार-बार इस्तेमाल किया गया User) User संसाधन अब टॉप-लेवल का संसाधन है और इसकी अपनी सेवा है.
AccountUser.email_address CreateUserRequest.user_id और User.name का हिस्सा उपयोगकर्ता का ईमेल पता अब संसाधन के नाम का हिस्सा है. इसे बनाते समय, user_id फ़ील्ड में डालें.
AccountUser.admin access_rights: "ADMIN" Merchant API में, बूलियन admin फ़ील्ड की जगह access_rights enum में ADMIN वैल्यू का इस्तेमाल किया जाता है.
AccountUser.order_manager, AccountUser.payments_manager, AccountUser.payments_analyst access_rights: "STANDARD" Merchant API में, इन भूमिकाओं की जगह STANDARD ऐक्सेस के अधिकार का इस्तेमाल किया जाता है.
AccountUser.reporting_manager access_rights: "PERFORMANCE_REPORTING" reporting_manager की भूमिका के लिए, अब PERFORMANCE_REPORTING ऐक्सेस के अधिकार का इस्तेमाल किया जाता है.
AccountUser.read_only access_rights: "READ_ONLY" read_only की भूमिका के लिए, अब READ_ONLY ऐक्सेस के अधिकार का इस्तेमाल किया जाता है.
उपलब्ध नहीं है User.name इसमें उपयोगकर्ता के संसाधन का पूरा नाम होता है. जैसे, accounts/{account}/users/{email}.
उपलब्ध नहीं है User.state इससे उपयोगकर्ता को भेजे गए न्योते की स्थिति पता चलती है. यह PENDING या VERIFIED हो सकती है.
पीछे जाएं
Migrate accountstatuses to Aggregate Product Statuses
आगे बढ़ें
Migrate homepage management