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

ב-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 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/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.

תיאור הבקשה	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.patch	עדכון הרשאות הגישה של משתמש.
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.