בדף הזה מופיעה סקירה כללית על השימוש בממשקי ה-API שמותקנים עם Vertex AI ב-Google Distributed Cloud (GDC) air-gapped, ועל מסמכי העיון שלו.
נקודת קצה של שירות ומסמך Discovery
כדי ליצור אינטראקציה באופן פרוגרמטי עם ממשקי Vertex AI API, צריך נקודת קצה של שירות.
קבלת נקודת הקצה ומסמך Discovery של Vertex AI Workbench
נקודת קצה ל-API של Vertex AI Workbench KRM היא:
https://ENDPOINT/apis/aiplatform.gdc.goog/v1
מחליפים את הערך ENDPOINT בנקודת קצה ל-API של שרת ה-Management API.
כדי לגשת למסמך Discovery של Vertex AI Workbench, מבצעים אחת מהפעולות הבאות:
מזינים את כתובת ה-URL של נקודת הקצה בדפדפן.
מריצים את הפקודה
kubectl proxyבכלי כמו curl כדי לפתוח Proxy לשרת Management API במחשב המקומי. אחרי שהפקודה הזו פועלת, מזינים את כתובת ה-URL הבאה בדפדפן:http://127.0.0.1:8001/apis/aiplatform.gdc.goog/v1.
קבלת נקודות הקצה של ממשקי ה-API שאומנו מראש
כדי לקבל את נקודות הקצה של ממשקי ה-API שאומנו מראש, צופים בסטטוס השירות ובנקודות הקצה.
REST, gRPC, KRM וספריות לקוח
אפשר לגשת לממשקי ה-API שאומנו מראש באמצעות gRPC או אחת מספריות הלקוח שסופקו. ספריות הלקוח מבוססות על gRPC.
לחלופין, אפשר לגשת לחלק מממשקי ה-API שעברו אימון מראש באמצעות REST.
אתם יכולים לנהל את Vertex AI Workbench באמצעות Kubernetes Resource Model (KRM) API.
ספריות לקוח
Vertex AI מספק ספריות לקוח של Python לממשקי API שעברו אימון מראש. בטבלה הבאה מוצגת השוואה בין היתרונות והחסרונות של שימוש בספריות לקוח:
| יתרונות | חסרונות |
|---|---|
|
בניהול של Google.
אימות מובנה. ניסיונות חוזרים מובנים. גוף בקשת HTTP יעיל של מאגר אחסון לפרוטוקולים. |
האפשרות הזו לא זמינה לכל שפות התכנות. |
REST
ממשקי ה-API ל-OCR ולתרגום תומכים ב-REST. מידע נוסף זמין בהפניות ל-API בארכיטקטורת REST של השירותים האלה:
בטבלה הבאה מוצגת השוואה בין היתרונות והחסרונות של שימוש ב-REST:
| יתרונות | חסרונות |
|---|---|
|
ממשק JSON פשוט.
יש תמיכה טובה ב-Google Cloud CLI בהרבה כלים וספריות של Google ושל צד שלישי. |
אתם צריכים ליצור לקוח משלכם.
צריך להטמיע אימות. חובה להטמיע ניסיונות חוזרים. תוכן בקשת HTTP בפורמט JSON פחות יעיל. ממשקי ה-API האלה לא תומכים בסטרימינג של REST. |
gRPC
ממשקי API מאומנים מראש תומכים ב-gRPC. למידע נוסף על התיאורים הכלליים של הסוגים, השיטות והשדות שנוצרים לספריית gRPC, אפשר לעיין במאמר הבא בנושא gRPC:
בטבלה הבאה מוצגת השוואה בין היתרונות והחסרונות של השימוש ב-gRPC:
| יתרונות | חסרון |
|---|---|
|
תמיכה בשפות תכנות רבות.
גוף בקשת HTTP יעיל של מאגר אחסון לפרוטוקולים. |
אתם צריכים ליצור לקוח משלכם ממאגרי פרוטוקולים שסופקו על ידי Google.
צריך להטמיע אימות. חובה להטמיע ניסיונות חוזרים. |
KRM
Vertex AI Workbench API תומך ב-KRM. מידע נוסף זמין במאמר Vertex AI Workbench KRM API reference.
סוג, שיטה ושמות שדות
בהתאם לשימוש בספריות לקוח, ב-REST, ב-gRPC או ב-KRM, הסוג, השיטה ושמות השדות של ה-API משתנים באופן הבא:
- ממשק REST מסודר לפי היררכיות של משאבים והשיטות שלהם.
- ספריות הלקוח ו-gRPC מסודרות לפי שירותים והשיטות שלהם.
- שמות השדות ב-KRM הם בפורמט CamelCase, אבל שירות ה-API מקבל גם פורמט CamelCase וגם פורמט snake_case.
- שמות השדות ב-REST וב-gRPC כתובים ב-snake_case.
- שמות השדות בספריית הלקוח הם באותיות רישיות בכל מילה (title case), בשיטת CamelCase או בשיטת snake_case, בהתאם לשם שמתאים לשפה.
REST ומאגרי אחסון לפרוטוקולים
כשקוראים ל-API בארכיטקטורת REST, התנהגות ברירת המחדל של מאגרי אחסון לפרוטוקולים עלולה לגרום לשדות חסרים בתגובת JSON. השדות האלה מוגדרים לערך ברירת המחדל, ולכן הם לא נכללים בתגובה.