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

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