انتقال مدیریت کاربر و دسترسی

در Content API for Shopping، کاربران و حقوق دسترسی آن‌ها را با فیلدی در منبع Account مدیریت می‌کردید. Merchant API این مورد را با منبع اختصاصی به‌نام User و روش‌های مربوطه (ایجاد، حذف، دریافت، فهرست، مسیر) جایگزین می‌کند. برای اطلاعات بیشتر، کنترل دسترسی به حساب را ببینید.

تفاوت‌های اصلی

درمقایسه با Content API ویژه 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 مقایسه می‌کند.

شرح درخواست	Content API for Shopping	میانای برنامه‌سازی کاربردی فروشنده
دریافت کاربران برای حساب	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	میانای برنامه‌سازی کاربردی فروشنده
شناسه حساب	accountId	‫account در accounts/{account}
شناسه کاربر	‫email_address در شیء AccountUser	‫email در accounts/{account}/users/{email}

روش‌ها

جدول زیر روش‌های Content API for Shopping و Merchant API را باهم مقایسه می‌کند.

Content API for Shopping	میانای برنامه‌سازی کاربردی فروشنده	دردسترس بودن و نکات
accounts.update	users.create	کاربر جدیدی برای حساب ایجاد می‌کند.
accounts.get	users.get	یک کاربر را بازیابی می‌کند.
accounts.get	users.list	همه کاربران یک حساب را فهرست می‌کند.
accounts.update	users.patch	حقوق دسترسی کاربر را به‌روز می‌کند.
accounts.update	users.delete	کاربری را از حساب حذف می‌کند.

تغییرات دقیق فیلد

استفاده‌تان از فیلدها را به‌صورت زیر به‌روز کنید:

Content API for Shopping	میانای برنامه‌سازی کاربردی فروشنده	شرح
‫users (AccountUser بار تکرار شد)	‫users (User بار تکرار شد)	منبع User اکنون منبعی در سطح بالا با سرویس خودش است.
AccountUser.email_address	‫CreateUserRequest.user_id و بخشی از User.name	نشانی ایمیل کاربر اکنون بخشی از نام منبع است. آن را در فیلد user_id هنگام ایجاد مشخص کنید.
AccountUser.admin	access_rights: "ADMIN"	Merchant API فیلد بولی admin را با مقدار ADMIN در شمارش access_rights جایگزین می‌کند.
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.