סקירה כללית

כדי להשתמש ביעילות ב-Merchant API, חשוב להבין את המושגים הרשמה, אימות והרשאה. לכל אחד מהם יש מטרה שונה בהבטחת גישה מאובטחת ונכונה לנתונים ב-Merchant Center.

הסברים על המונחים

רישום, אימות והרשאה הם מושגים קשורים, אבל לכל אחד מהם יש משמעות ומטרה שונות.

• אימות: בתהליך הזה השירות מאמת את הזהות של המשתמש או האפליקציה ששולחים בקשת API. ב-Merchant API נעשה שימוש במנגנונים סטנדרטיים של Google, כמו OAuth 2.0. מידע נוסף זמין במאמרים בנושא אימות בקשות ואימות כחשבון שלכם.
• הרשאה: בתהליך הזה נקבע אילו פעולות מותר למשתמש או לאפליקציה מאומתים לבצע באמצעות חשבון Merchant Center. התשובה לשאלה 'מה אתה יכול לעשות?' מבוססת על התפקידים וההרשאות שניתנו למשתמש המאומת בחשבון Merchant Center. לדוגמה, יכול להיות שמשתמש יורשה לקרוא נתוני מוצרים, אבל לא לשנות את הגדרות החשבון.
• הרשמה: כשמדובר ב-Merchant API, זהו תהליך חד-פעמי של הגדרה שמאפשר ל-Google לשלוח לכם הודעות חשובות על שירותים לגבי חשבונות המוכרים שאתם מנהלים. במהלך הרישום, כתובות האימייל של המפתחים מתווספות לחשבון הראשי שלכם ב-Merchant Center והוא מקושר למזהי הפרויקטים ב-Google Cloud שבהם אתם משתמשים לאימות. הקישור הזה מאפשר לאפליקציה שלכם לקבל הודעות על שירותים לכל חשבונות המוכרים שאתם מנהלים. מידע נוסף זמין במאמר יצירת פרויקט ב-Google Cloud.

הרשמה

תהליך ההרשמה חיוני כדי לאפשר לאפליקציה שלכם להשתמש ב-Merchant API. דברים שעליך לדעת:

דרישות מוקדמות

כדי להירשם לשימוש ב-Merchant API, צריך:

• חשבון Merchant Center: צריך להיות לכם חשבון קיים ב-Merchant Center.
• גישת אדמין: לחשבון המשתמש שלכם ב-Google שבו אתם משתמשים כדי להתחיל את שיחת ההרשמה צריכות להיות הרשאות אדמין בחשבון Merchant Center שאתם רושמים.
• פרויקט ב-Google Cloud: האפליקציה שלכם צריכה להיות משויכת לפרויקט ב-Google Cloud. הפרויקט הזה מספק את פרטי הכניסה הנדרשים (כמו מזהי לקוח של OAuth 2.0) כדי שהאפליקציה תאומת.

למה אי אפשר לרשום פרויקט משותף ב-Google Cloud

כלים כמו Google OAuth Playground ו-APIs Explorer משתמשים בפרויקטים משותפים ב-Google Cloud שנמצאים בבעלות Google. אי אפשר להירשם לפרויקטים משותפים כי:

• הם מיועדים לבדיקה ולניסוי, ולא לזהות של אפליקציה בסביבת הייצור.
• הרשמה שלהם מרמזת על קישור בין הכלי המשותף לבין נתונים ספציפיים שלכם ב-Merchant Center, ועלולה להוביל לתקשורת לא רצויה.

האפליקציה שלכם צריכה פרויקט ייעודי משלה ב-Google Cloud, כדי שהתקשורת של Merchant API ש-Google שולחת לכם תישאר רלוונטית לשימוש בפועל.

עם זאת, אתם יכולים להשתמש באפליקציות האינטרנט OAuth Playground ו-API Explorer כדי להשתמש ב-Merchant API למטרות ניסויים ולתרחישי שימוש שאינם בסביבת ייצור.

איפה מופיע מזהה הפרויקט ב-Google Cloud

אפשר לראות את מזהה הפרויקט ומספר הפרויקט במסוף Google Cloud. מידע נוסף מופיע במאמר בנושא איך מוצאים את השם, המספר והמזהה של הפרויקט.

טיפ: מזהה הפרויקט הוא מחרוזת ייחודית, ומספר הפרויקט הוא מספר שלם ייחודי. בדרך כלל משתמשים במספר הפרויקט בתהליך הרישום.

ביצוע שיחת הרישום

נרשמים באמצעות השיטה registerGcp ב-sub-API‏ Accounts. הקריאה הזו משייכת את מספר הפרויקט ב-Google Cloud לחשבון Merchant Center.

במהלך התהליך, צריך לספק כתובת אימייל שמשויכת למשתמש יחיד שמשמש לקריאה ל-API. כתובת האימייל הזו צריכה להיות של משתמש עם הרשאת אדמין לחשבון Merchant Center.

מידע על שדה האימייל

תקשורת יעילה היא המפתח. ‫Google שולחת עדכונים חשובים, הודעות חיוניות על שירותים (MSA), סקרים למפתחים והזדמנויות אחרות שקשורות ל-Merchant API. ניהול נכון של אנשי הקשר מבטיח שההודעות האלה יגיעו לאנשים הנכונים.

• מטרה: Google משתמשת בכתובת האימייל הזו כאיש קשר ראשי לתקשורת שקשורה ל-API.
• כתובת האימייל של מי: כאן צריך להזין את כתובת האימייל של מפתח יחיד או של איש קשר טכני מרכזי שאחראי לשילוב ה-API.
• שיטות מומלצות:
  • כן: צריך להשתמש בכתובת אימייל ארגונית של אדם מסוים.
  • אל: תשתמשו בכינויים כלליים של קבוצות או בכתובות אימייל של חשבונות שירות. התקשורת שלנו מיועדת לנמענים אנושיים.

משאב users לניהול אנשי קשר

כתובת האימייל שמוגדרת בקריאת ההרשמה משמשת כאיש קשר ראשוני, אבל הדרך היעילה יותר לנהל אנשי קשר והרשאות היא באמצעות המשאב Merchant API accounts.users או הגדרות ניהול המשתמשים בממשק המשתמש של Merchant Center. מידע נוסף על השימוש ב-Merchant Center זמין במאמר ניהול משתמשים בחשבון.

כך תוכלו להשתמש בתכונות האלה:

1. הוספת כל המפתחים: הוספת המפתחים שעובדים על שילוב ה-API כמשתמשים בחשבון Merchant Center.
2. הקצאת התפקיד API_DEVELOPER: בנוסף לתפקידים הרגילים (אדמין, רגיל), אפשר להקצות למשתמשים את התפקיד API_DEVELOPER. בפרט, כדאי להקצות את התפקיד הזה למשתמשים שצריכים לקבל עדכונים שקשורים ל-API. אפשר לשלב אותו עם תפקידים אחרים.
3. יתרונות:
   • הפרדה ברורה: ניהול אנשי הקשר ב-API מופרד מההרשמה החד-פעמית.
   • גמישות: אפשר לעדכן את אנשי הקשר כשחברי הצוות משתנים.
   • תקשורת ממוקדת: מוודאת שחדשות שקשורות ל-API ספציפי מגיעות לאנשים הרלוונטיים.

גם אם סיפקתם כתובת אימייל במהלך ההרשמה, מומלץ מאוד לנהל את אנשי הקשר של ממשק ה-API על ידי הוספת משתמשים עם התפקיד API_DEVELOPER.

קובצי עזר

למידע נוסף, קראו את המאמרים הבאים:

• מדריך למתחילים
• ‫DeveloperRegistration methods