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

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/[e-mail].
• 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.update	यह कुकी, उपयोगकर्ता के ऐक्सेस के अधिकारों को अपडेट करती है.
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 में से कोई एक हो सकती है.