בחירת אפשרות של Endpoints

כדי שממשק ה-API שלכם ינוהל על ידי Cloud Endpoints, יש שלוש אפשרויות, בהתאם למיקום האירוח של ממשק ה-API ולסוג פרוטוקול התקשורת שבו משתמש ממשק ה-API:

בדף הזה מוסבר על אפשרויות נקודות הקצה (Endpoints) כדי לעזור לכם להחליט איזו מהן מתאימה לכם.

בחירת אפשרות מחשוב

נקודות קצה תומכות באפשרויות שונות של Google Cloud מחשוב שיכולות לארח את קוד ה-Backend של ה-API. ‫Endpoints פועל עם Extensible Service Proxy (ESP) או עם Extensible Service Proxy V2 (ESPv2) כדי לספק ניהול של ממשקי API. בטבלה הבאה מפורטות אפשרויות המחשוב הנתמכות:

‫ESP for OpenAPI ESP for gRPC ‫ESPv2 ל-OpenAPI ‫ESPv2 ל-gRPC Endpoints Frameworks
‫App Engine
דור 1 של סביבה רגילה		 סביבות ריצה של Java 8 ו-Python 2.7
‫App Engine
דור 2 של הסביבה הסטנדרטית
הסביבה הגמישה של App Engine
פונקציות Cloud Run
Cloud Run
מילוי בקשות מסוג Knative
Compute Engine
GKE
‫Kubernetes
אחרGoogle Cloud

השוואה בין התכונות שמסופקות על ידי App Engine,‏ GKE ו-Compute Engine מופיעה במאמר בחירת אפשרות מחשוב. אם אתם מתכננים להשתמש ב-App Engine, אתם צריכים לבחור בין סביבה סטנדרטית לסביבה גמישה. להשוואה בין שתי הסביבות, ראו בחירת סביבת App Engine.

מידע על מגבלות האפשרויות של המחשוב

נקודות קצה (endpoint) של OpenAPI ונקודות קצה של gRPC יכולות להשתמש ב-ESP או ב-ESPv2 כפרוקסי. בפלטפורמות שאינן מבוססות על שרתים, ESP או ESPv2 נפרסים כקונטיינר לפני האפליקציה או כ-sidecar עם האפליקציה. בפלטפורמות ללא שרת, כמו Cloud Run,‏ Cloud Run Functions ו-App Engine,‏ ESPv2 נפרס כשירות Cloud Run בתור שרת proxy מרוחק לניהול אפליקציות בפלטפורמה ללא שרת.

אחרי שמבצעים פריסה של קוד ה-Backend של ה-API, ‏ ESP או ESPv2 מיירטים את כל הבקשות ומבצעים את כל הבדיקות הנדרשות (כמו אימות) לפני שהם מעבירים את הבקשה ל-Backend של ה-API. כששרת הקצה העורפי מגיב, ESP אוסף ומדווח על טלמטריה באמצעות Service Infrastructure.

בדף Endpoints Services בGoogle Cloud מסוף אפשר לראות מדדים של ה-API וקישורים ליומנים ולעקבות של Google Cloud Observability.

מגבלות בסביבה רגילה של App Engine, דור 1

בעבר, נקודות הקצה של סביבת App Engine סטנדרטית דור 1 השתמשו ב-Endpoints Frameworks, שתומך רק בסביבות זמן הריצה Java 8 ו-Python 2.7.

בזמן הפיתוח של Endpoints Frameworks, סביבת App Engine הרגילה לא תמכה בפריסות של כמה קונטיינרים, ולכן Endpoints Frameworks לא משתמש ב-ESP. במקום זאת, Endpoints Frameworks כולל שער API מובנה, שמספק תכונות לניהול API שדומות לתכונות ש-ESP מספק ל-Endpoints for OpenAPI ול-Endpoints for gRPC.

ממשקי gRPC API לא נתמכים ב-App Engine או בפונקציות של Cloud Run

‫gRPC הוא פריימוורק של קריאה לשירות מרוחק (RPC) שיכול לפעול בכל סביבה. באמצעות gRPC, אפליקציית לקוח יכולה לקרוא ישירות למתודות באפליקציית שרת במכונה אחרת, כאילו מדובר באובייקט מקומי. התכונה העיקרית של gRPC היא סטרימינג דו-כיווני עם העברה מבוססת HTTP/2.

פונקציות App Engine ו-Cloud Run לא תומכות ב-HTTP/2.

שפות תכנות נתמכות

תיאור ה-API

אפשרויות ה-Endpoints מספקות דרכים שונות לתאר את ה-API.

נקודות קצה ל-OpenAPI

OpenAPI Initiative הוא מאמץ כלל-תעשייתי לתקנן את התיאור של ממשקי REST API. ‫Endpoints תומך בממשקי API שמתוארים באמצעות OpenAPI 2.0 ו-OpenAPI 3.x של מפרט OpenAPI (לשעבר מפרט Swagger). מידע נוסף זמין במאמר גרסאות נתמכות של OpenAPI. מתארים את הפלטפורמה של ה-API בקובץ JSON או YAML (שנקרא מסמך OpenAPI). אפשר להטמיע את ה-API באמצעות כל מסגרת REST שזמינה לציבור, כמו Django או Jersey. אם אתם לא מכירים את מפרט OpenAPI, תוכלו לעיין בסקירה כללית של OpenAPI.

מידע נוסף זמין במאמר נקודות קצה (endpoint) ל-OpenAPI.

נקודות קצה ל-gRPC

ב-gRPC, מגדירים את מבנה הנתונים שרוצים לבצע לו סריאליזציה בקובץ proto: זהו קובץ טקסט רגיל עם סיומת .proto. בנוסף, מגדירים את הפלטפורמה של ה-API בקובצי ‎.proto, עם פרמטרים של שיטת RPC וסוגי החזרה שמוגדרים כהודעות של מאגר אחסון לפרוטוקולים. אם אתם לא מכירים את gRPC, כדאי לעיין במאמר מה זה gRPC? במסמכי התיעוד של gRPC.

מידע נוסף זמין במאמר נקודות קצה (endpoint) של gRPC.

מסגרות של נקודות קצה

‫Endpoints Frameworks הוא framework לאינטרנט עבור סביבות זמן הריצה של Python 2.7 ו-Java 8 ב-App Engine. מוסיפים מטא-נתונים (באמצעות הערות ב-Java או מעצבים ב-Python) לקוד המקור. המטא-נתונים מתארים את המשטח של ממשקי ה-API ל-REST של האפליקציה.

מידע נוסף זמין במאמר בנושא מסגרות של נקודות קצה.

המאמרים הבאים