העברת ניהול משתמשים וגישה

ב-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 alias: אפשר להשתמש בכינוי me במקום בכתובת אימייל בשם המשאב כדי להתייחס למשתמש המאומת, לדוגמה, accounts/12345/users/me.
• איחוד הרשאות הגישה: Merchant API מאחד שדות של גישה בוליאנית מ-Content API (לדוגמה, admin,‏ reportingManager) לשדה יחיד שניתן לחזרהaccess_rights.
• הזמנת משתמשים ואימותם: ב-Merchant API נוסף סטטוס משתמש מפורש (PENDING או VERIFIED). כשיוצרים משתמש חדש, הסטטוס שלו הוא PENDING עד שהוא מאשר את ההזמנה. התכונה הזו מאפשרת ל-API לראות את הסטטוס של המשתמש, מה שלא היה אפשרי ב-Content API for Shopping. הוספה ## בקשות

ב-Merchant API נעשה שימוש בכתובות ה-URL הבאות של בקשות לניהול משתמשים:

• GET /accounts/v1beta/accounts/{account}/users/{email}
• GET /accounts/v1beta/accounts/{account}/users
• POST /accounts/v1beta/accounts/{account}/users
• PATCH /accounts/v1beta/accounts/{account}/users/{email}
• DELETE /accounts/v1beta/accounts/{account}/users/{email}

בטבלה הבאה מוצגות השוואה בין כתובות ה-URL של הבקשות ב-Content API for Shopping וב-Merchant API.

תיאור הבקשה	Content API for 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.

תיאור המזהה	Content API for Shopping	Merchant API
מזהה החשבון	accountId	account ב-accounts/{account}
מזהה משתמש	email_address באובייקט AccountUser	email ב-accounts/{account}/users/{email}

Methods

בטבלה הבאה מוצגות השוואה בין השיטות של Content API for Shopping ו-Merchant API.

Content API for Shopping	Merchant API	זמינות והערות
accounts.update	users.create	יוצר משתמש חדש בחשבון.
accounts.get	users.get	מאחזר משתמש יחיד.
accounts.get	users.list	רשימה של כל המשתמשים בחשבון.
accounts.update	users.update	עדכון של זכויות הגישה של משתמש.
accounts.update	users.delete	מחיקת משתמש מחשבון.

שינויים מפורטים בשדות

מעדכנים את השימוש בשדות באופן הבא:

Content API for 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 ב-enum‏ 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.