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

في 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.