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

في 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.update تعدِّل هذه الطريقة حقوق الوصول الخاصة بمستخدم.
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.