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

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 में उपलब्ध नहीं थी. Add ## अनुरोध

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 हो सकती है.