نقل إدارة المستخدمين وأذونات الوصول

في 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 عناوين URL التالية للطلبات من أجل إدارة المستخدمين:

• 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}

يقارن الجدول التالي بين عناوين URL الخاصة بالطلبات في Content API for Shopping وMerchant API.

وصف الطلب	واجهة برمجة تطبيقات المحتوى في 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.

وصف المعرّف	واجهة برمجة تطبيقات المحتوى في Shopping	Merchant API
معرّف الحساب	accountId	account في accounts/{account}
معرّف المستخدم	‫email_address ضمن العنصر AccountUser	email في accounts/{account}/users/{email}

الطُرق

يقارن الجدول التالي بين طرق Content API for Shopping وMerchant API.

واجهة برمجة تطبيقات المحتوى في Shopping	Merchant API	التوفّر والملاحظات
accounts.update	users.create	تُنشئ هذه الطريقة مستخدمًا جديدًا لحساب.
accounts.get	users.get	تعرض هذه الطريقة مستخدمًا واحدًا.
accounts.get	users.list	تعرض هذه الطريقة قائمة بجميع المستخدمين لحساب معيّن.
accounts.update	users.patch	تعديل حقوق الوصول الخاصة بمستخدم
accounts.update	users.delete	يحذف هذا الإجراء مستخدمًا من حساب.

التغييرات التفصيلية في الحقول

عدِّل استخدامك للحقول على النحو التالي:

واجهة برمجة تطبيقات المحتوى في 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 بالقيمة 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.