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

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

मुख्य अंतर

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 के अनुरोध यूआरएल की तुलना की गई है.

अनुरोध का ब्यौरा Shopping के लिए Content API 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 के बीच अनुरोधों में इस्तेमाल किए गए आइडेंटिफ़ायर की तुलना की गई है.

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

तरीके

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

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

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

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

Shopping के लिए Content API 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