יצירת שרת proxy פשוט ל-API

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

הערה: בסביבות שמופעלות בהן פריסות של ארכיון, אי אפשר ליצור שרתי proxy של API באמצעות ממשק המשתמש של Apigee, ה-API או gcloud. כדי ליצור שרתי proxy ל-API לפריסות של ארכיון באמצעות Apigee ב-VS Code,אפשר לעיין במאמר פיתוח שרתי proxy ל-API באמצעות Apigee ב-VS Code.

‫Apigee מאפשר לכם לחשוף במהירות שירותים לקצה העורפי בתור ממשקי API. כדי לעשות זאת, יוצרים שרת proxy של API שמספק חזית לשירות הקצה העורפי שרוצים לחשוף. צריך לספק רק את כתובת הרשת של שירות לקצה העורפי, יחד עם מידע ש-Apigee משתמש בו כדי ליצור את proxy ל-API שמוצג למפתחים.

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

בנושא הזה מוסבר על הסוגים השונים של שרתי proxy ועל ההגדרות שלהם. הוראות מפורטות ליצירת שרתי proxy מופיעות בנושאים הבאים:

• הדרכה: יצירת proxy ל-API ראשון
• יצירת proxy ל-API

יצירת proxy ל-API באמצעות ממשק המשתמש

הדרך הכי קלה ליצור proxy ל-API היא באמצעות האשף Create Proxy.

1. במסוף Google Cloud , נכנסים לדף Apigee > Proxy development > API proxies.

   מעבר לשרתי proxy ל-API

2. לוחצים על ‎+ Create.

מוצג האשף Create Proxy, שמוביל אתכם בשלבים ליצירה ולהוספה של תכונות מינימליות ל-proxy ל-API.

האשף מאפשר לכם ליצור proxy ל-API מהמקורות הבאים:

קטגוריה	סוג	תיאור
תבנית כללית	שרת proxy הפוך (הכי נפוץ)	proxy ל-API שמנתב בקשות נכנסות לשירותי קצה עורפיים קיימים של HTTP. יכול להיות API בפורמט JSON או API בפורמט XML. בהמשך הקטע הזה מוסבר איך יוצרים שרת proxy הפוך לשירות HTTP.
	ללא יעד	‫proxy ל-API ללא קצה עורפי של API ('ללא יעד'). בדומה ליצירת שרת proxy הפוך לשירות HTTP שמתואר למעלה, רק שלא מציינים API קיים כשמגדירים את פרטי ה-proxy ל-API.
	העלאת חבילת proxy	חבילת שרתי proxy ל-API קיימת (לדוגמה, אחת מדוגמאות השרתים ל-API שזמינות ב-GitHub). ראו ייבוא שרת proxy ל-API מחבילת שרתי proxy ל-API.
	Proxy עם אירועים שנשלחים מהשרת (SSE)	proxy ל-API שכולל EventFlow לעיבוד סטרימינג של אירועים שנשלחים מהשרת (SSE). מידע נוסף זמין במאמר בנושא עיבוד סטרימינג של אירועים שנשלחים מהשרת.
תבנית מבוססת-AI	מגבלת טוקנים בהנחיה	בדומה למדיניות למניעת עליות פתאומיות בשימוש, המדיניות הזו עוזרת לכם לשלוט בקצב השימוש באסימונים מהנחיות משתמשים כדי למנוע ניצול לרעה. מידע נוסף זמין במאמר תחילת העבודה עם מדיניות אסימוני AI ב-Apigee.
	מכסת טוקנים של LLM	ניהול וצמצום צריכת הטוקנים בשיחות עם ממשקי LLM API. מידע נוסף זמין במאמר תחילת העבודה עם מדיניות אסימוני AI ב-Apigee.
	שרת proxy עם הגנה מוגברת על המודל	מבטיח אינטראקציות בטוחות עם AI על ידי ניקוי ההנחיות של המשתמשים והתשובות של המודל. מידע נוסף זמין במאמר תחילת העבודה עם מדיניות Apigee הגנה מוגברת על המודל.
	שרת proxy עם מטמון סמנטי	שמירת תשובות במטמון לבקשות דומות, כדי לשפר את זמן התגובה ואת הקריאות ל-LLM. מידע נוסף זמין במאמר איך מתחילים להשתמש במדיניות שמירה במטמון סמנטי.
תבנית של מפרט OpenAPI	שרת proxy הפוך (הכי נפוץ)	יוצרים את ה-proxy ממפרט OpenAPI תקין. מידע נוסף על האפשרות הזו מופיע בהמשך הקטע במאמר בנושא שימוש במפרטי OpenAPI ליצירת שרתי proxy.
	ללא יעד	‫proxy ל-API ללא קצה עורפי של API ('ללא יעד'). בדומה ליצירת שרת proxy הפוך לשירות HTTP שמתואר למעלה, רק שבמקרה הזה לא מציינים API קיים כשמגדירים את פרטי ה-proxy ל-API.

בקטעים הבאים מפורטים סוגי ה-proxy השונים.

יצירת שרת proxy הפוך לשירות HTTP

‫Apigee יוצר פרוקסי הפוך על סמך המידע הבא:

• כתובת ה-URL של השירות לקצה העורפי.
• נתיב URI שמזהה באופן ייחודי את ה-API שיוצג על ידי ה-proxy ל-API לאפליקציות צרכניות.

כתובת ה-URL של שירות לקצה העורפי מייצגת בדרך כלל אפליקציה שמופעל בה שירות, והיא בבעלות הארגון שלכם. היא יכולה גם להפנות לממשק API שזמין לציבור. יכול להיות שממשק ה-API או השירות נמצאים בשליטתכם (לדוגמה, אפליקציית משאבי אנוש פנימית או אפליקציית Rails ב-Cloud), או שמדובר בממשק API או בשירות של צד שלישי (לדוגמה, Twitter או אינסטגרם).

אחרי שנכנסים אל האשף ליצירת שרת proxy ובוחרים סוג של שרת proxy, הפרטים הבאים של ה-proxy זמינים:

שדה	תיאור
שם	השם שמוצג עבור ה-API. צריך לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_).
נתיב בסיסי	קטע URI שמופיע אחרי הכתובת http://[host] או https://[host] של שרת ה-proxy של ה-API. מערכת Apigee משתמשת ב-URI של נתיב הבסיס כדי להתאים ולנתב הודעות בקשה נכנסות לשרת ה-proxy המתאים של ה-API. הערה: נתיב הבסיס של ה-proxy ל-API מוגדר כברירת מחדל לערך שצוין בשדה Name, שהומר לאותיות קטנות בלבד. אחרי נתיב הבסיס מופיעות כתובות URL נוספות של משאבים. מבנה כתובת ה-URL המלאה שבה הלקוחות משתמשים כדי לקרוא ל-proxy ל-API הוא כדלקמן: https://[host]/BASE_PATH/CONDITIONAL_FLOW_PATH הערה: נתיב הבסיס צריך להיות ייחודי. אי אפשר לפרוס שני שרתי proxy של API עם אותו נתיב בסיס. אם עורכים proxy ל-API שנפרס ומגדירים את נתיב הבסיס לאותו ערך כמו נתיב הבסיס של proxy אחר ל-API, מערכת Apigee מבטלת את הפריסה של ה-proxy ל-API באופן אוטומטי כששומרים אותו. כדי לפרוס מחדש את proxy ל-API, צריך לערוך את נתיב הבסיס כך שיהיה ייחודי. שימוש בתווים כלליים בנתיבי בסיס כדי להבטיח שה-proxy ל-API שלכם ימשיכו לפעול גם בעתיד, כדאי להשתמש בתו כללי אחד או יותר של /*/ בנתיבי הבסיס של ה-proxy ל-API. לדוגמה, נתיב בסיסי של /team/*/members מאפשר ללקוחות לבצע קריאה ל-https://[host]/team/blue/members ול-https://[host]/team/green/members בלי שתצטרכו ליצור שרתי proxy חדשים של API כדי לתמוך בצוותים חדשים. שימו לב: אין תמיכה ב-/**/.
תיאור	(אופציונלי) תיאור של ה-API.
יעד (API קיים)	כתובת ה-URL של שירות לקצה העורפי שה-proxy ל-API הזה מפעיל.

ייבוא של Proxy ל-API מחבילת Proxy ל-API

הערה: כשמייבאים proxy ל-API מחבילת proxy ל-API, אתם אחראים להגדרת האבטחה בחבילה ולהוספת מדיניות לחבילה. בממשק המשתמש לא מוצגת בקשה להוסיף אבטחה או מדיניות כשמייבאים את החבילה, כמו שמתואר בקטע הוספת אבטחה בהמשך.

לרוב מגדירים שרתי proxy של API כאוסף של קובצי XML, יחד עם קבצים תומכים אחרים. אם מגדירים את שרתי ה-proxy של ה-API כקבוצה של קבצים חיצוניים ל-Apigee, אפשר לתחזק אותם במערכת בקרת מקורות, ואז לייבא אותם ל-Apigee לצורך בדיקה ופריסה.

כדי לייבא שרתי proxy ל-API מחבילת שרתי proxy ל-API:

1. ניגשים לאשף Create Proxy (יצירת שרת proxy) כמו שמתואר במאמר יצירת שרת proxy ל-API באמצעות ממשק המשתמש.
2. מציינים את פרטי חבילת שרת ה-proxy ל-API.
1. בתפריט תבנית של שרת Proxy, בוחרים באפשרות העלאת חבילת שרת Proxy.
2. בקטע פרטי ה-Proxy, מזינים את שם ה-Proxy, מעלים את קובץ ה-ZIP ולוחצים על הבא.
3. בקטע פריסה, בוחרים את סביבות הפריסה הרצויות ולוחצים על יצירה.

יצירת שרתי proxy של gRPC API

בנוסף לשרתי Proxy של API בארכיטקטורת REST, ‏ Apigee תומך בשרתי Proxy של gRPC API עם תמיכה בהעברה בלבד בשלב הזה. עם תמיכה בהעברה, מטען ה-payload של gRPC הוא אטום ל-Apigee, והתנועה מנותבת מלקוח gRPC לשרת היעד של gRPC שהוגדר מראש בהגדרת היעד.

בשלב הזה, proxy ל-API של gRPC ב-Apigee:

• תמיכה בבקשות gRPC אונריות.
• אי אפשר להשתמש במדיניות שמשפיעה על מטען הייעודי (payload).
• אפשר להשתמש בו במוצרי API שלא משויכים לשרתי proxy של GraphQL או REST. מכסות ספציפיות למוצר API והגדרות פעולה אחרות חלות על כל שרתי ה-proxy במוצר.
• לא נתמכות ב-Apigee hybrid.
• משתמשים בשני משתני זרימה ספציפיים ל-gRPC: ‫request.grpc.rpc.name ו-request.grpc.service.name.
• אפשר לעקוב אחריו באמצעות משתני Apigee Analytics הספציפיים ל-gRPC: ‫x_apigee_grpc_rpc_name, x_apigee_grpc_service_name ו-x_apigee_grpc_status.
• החזרת קודי סטטוס של gRPC.

צריך גם להגדיר את מאזן העומסים כך שיתמוך ב-gRPC. אפשר לעיין במאמרים שימוש ב-gRPC באפליקציות ושימוש בפקודות ה-CLI של gcloud ליצירת ניתוב ל-gRPC.

כדי ליצור proxy ל-API של gRPC, קודם צריך להגדיר שרת יעד של gRPC (ראו יצירת שרתי יעד), ואז לציין את שרת היעד הזה כשיוצרים את ה-proxy החדש.

שימוש בפקודות של ה-CLI של gcloud כדי ליצור ניתוב ל-gRPC

בקטע הזה מוצגות פקודות לדוגמה ליצירת ניתוב לשרתי proxy של gRPC באמצעות ה-CLI של gcloud. ההוראות כוללות הגדרה של מאזני עומסים, שרת יעד ו-MIG.

הקטע הזה לא נועד להיות מדריך מקיף ליצירת ניתוב. יכול להיות שהדוגמאות האלה לא מתאימות לכל תרחישי השימוש. בנוסף, ההוראות האלה מבוססות על ההנחה שאתם מכירים את הניתוב החיצוני (MIG) ואת ההגדרה של איזון עומסים ב-Cloud באמצעות gRPC.

הגדרה של משתני סביבה

משתני הסביבה האלה משמשים בפקודות שבקטעי המשנה.

PROJECT_ID=YOUR_PROJECT_ID
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=default
VPC_SUBNET=default
REGION=REGION_NAME
APIGEE_ENDPOINT=ENDPOINT
CERTIFICATE_NAME=CERTIFICATE_NAME
DOMAIN_HOSTNAME=DOMAIN_HOSTNAME

דוגמאות לפקודות של ה-CLI של gcloud ליצירת ניתוב לשרתי proxy של gRPC באמצעות מאזני עומסים חדשים

בקטע הזה מוצגות פקודות לדוגמה ליצירת שרתי proxy של gRPC באמצעות ה-CLI של gcloud ומאזן עומסים חדש. ההוראות כוללות הגדרה של מאזן העומסים, שרת יעד ו-MIG.

יצירת תבנית של הגדרות מכונה

gcloud compute instance-templates create $MIG_NAME \
--project $PROJECT_ID \
--region $REGION \
--network $VPC_NAME \
--subnet $VPC_SUBNET \
--tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
--machine-type e2-medium --image-family debian-12 \
--image-project debian-cloud --boot-disk-size 20GB \
--no-address \
--metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh

יצירת קבוצת מופעי מכונה מנוהלים

gcloud compute instance-groups managed create $MIG_NAME \
--project $PROJECT_ID --base-instance-name apigee-mig \
--size 2 --template $MIG_NAME --region $REGION

הגדרת התאמה אוטומטית לעומס

gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
--project $PROJECT_ID --region $REGION --max-num-replicas 50 \
--target-cpu-utilization 0.75 --cool-down-period 90

הגדרת יציאה עם שם

gcloud compute instance-groups managed set-named-ports $MIG_NAME \
--project $PROJECT_ID --region $REGION --named-ports https:443

יצירת אישור ומפתח SSL בניהול Google למאזן העומסים

gcloud compute ssl-certificates create $CERTIFICATE_NAME \
--domains=$DOMAIN_HOSTNAME \
--project $PROJECT_ID \
--global

אימות שהאישור הוקצה

gcloud compute ssl-certificates describe $CERTIFICATE_NAME \
--global \
--format="get(name,managed.status, managed.Status)"

יצירת מאזן עומסים גלובלי (GCLB) ב-Cloud

1. יצירת בדיקת תקינות
   

   gcloud compute health-checks create https hc-apigee-envoy-443 \
   --project $PROJECT_ID --port 443 --global \
   --request-path /healthz/ingress

2. יצירת שירות לקצה העורפי עבור http1
   

   gcloud compute backend-services create YOUR_BACKEND_1 \
   --project $PROJECT_ID \
   --protocol HTTPS \
   --health-checks hc-apigee-envoy-443 \
   --port-name https \
   --timeout 302s \
   --connection-draining-timeout 300s \
   --global

3. יצירת שירות לקצה העורפי עבור http2
   

   gcloud compute backend-services create YOUR_BACKEND_2 \
   --project $PROJECT_ID \
   --protocol HTTP2 \
   --health-checks hc-apigee-envoy-443 \
   --port-name https \
   --timeout 302s \
   --connection-draining-timeout 300s \
   --global

4. מוסיפים קבוצות של מכונות מנוהלות (MIGs) לשירות לקצה העורפי. בדוגמה הזו אנחנו משתמשים מחדש ב-MIG, אבל אפשר גם ליצור זוג חדש של MIG.
   

   gcloud compute backend-services add-backend YOUR_BACKEND_1 \
   --project $PROJECT_ID --instance-group $MIG_NAME \
   --instance-group-region $REGION \
   --balancing-mode UTILIZATION --max-utilization 0.8 --global

   gcloud compute backend-services add-backend YOUR_BACKEND_2 \
   --project $PROJECT_ID --instance-group $MIG_NAME \
   --instance-group-region $REGION \
   --balancing-mode UTILIZATION --max-utilization 0.8 --global

5. יוצרים מפת URL לאיזון עומסים. קודם בודקים אם כבר יש לכם מפת URL. אם כן, חשוב לשנות את המפה בהתאם לדרישות שבהמשך, ולא להחליף אותה.
   

   יוצרים קובץ YAML או משתמשים בקובץ קיים במיקום /tmp/apigee-map.yaml עם ההגדרה הזו. שימו לב: ברירת המחדל היא קצה עורפי מסוג http1 של מפת URL.

   defaultService: projects/$PROJECT_ID/global/backendServices/YOUR_BACKEND_1
   name: matcher1
   routeRules:
   - matchRules:
   - headerMatches:
   - headerName: Content-Type
   prefixMatch: application/grpc
   prefixMatch: /
   priority: 100
   routeAction:
   weightedBackendServices:
   - backendService: projects/$PROJECT_ID/global/backendServices/YOUR_BACKEND_2
   weight: 100

   מאמתים את מפת ה-URL:

   gcloud compute url-maps validate --source /tmp/apigee-map.yaml --project $PROJECT_ID

   יוצרים את מיפוי כתובות ה-URL עם ניתוב מבוסס-כותרת:

   gcloud compute url-maps import apigee-http1-http2 \
   --source /tmp/apigee-map.yaml  \
   --global --project $PROJECT_ID

יצירת Proxy ל-HTTPS עם יעד לאיזון עומסים

gcloud compute target-https-proxies create apigee-envoy-https-proxy \
--project $PROJECT_ID --url-map apigee-envoy-proxy-map \
--ssl-certificates $CERTIFICATE_NAME

שמירת כתובת IP חיצונית מסוג IPv4 ויצירת כללי חומת אש למאזן העומסים

gcloud compute addresses create lb-ipv4-vip-1 \
--project $PROJECT_ID \
--network-tier=PREMIUM \
--ip-version=IPV4 \
--global

  gcloud compute addresses describe lb-ipv4-vip-1 \
--project $PROJECT_ID --format="get(address)" --global

  gcloud compute forwarding-rules create apigee-envoy-https-lb-rule \
--project $PROJECT_ID --address lb-ipv4-vip-1 --global \
--target-https-proxy apigee-envoy-https-proxy --ports 443

יצירת כלל חומת אש

gcloud compute firewall-rules create k8s-allow-lb-to-apigee-envoy \
--description "Allow incoming from GLB on TCP port 443 to Apigee Proxy" \
--project $PROJECT_ID --network $VPC_NAME --allow=tcp:443 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 --target-tags=gke-apigee-proxy

דוגמאות לפקודות ב-CLI של gcloud ליצירת ניתוב לשרתי proxy של gRPC למאזני עומסים קיימים

בקטע הזה מוצגות פקודות לדוגמה ליצירת שרתי proxy של gRPC באמצעות ה-CLI של gcloud ומאזן עומסים קיים. ההוראות כוללות הגדרה של מאזן העומסים, שרת יעד ו-MIG.

יצירת שירות קצה עורפי נוסף ל-http2

# Create backend service for http2
    gcloud compute backend-services create YOUR_BACKEND_2 \
--project $PROJECT_ID \
--protocol HTTP2 \
--health-checks hc-apigee-envoy-443 \
--port-name https \
--timeout 302s \
--connection-draining-timeout 300s \
--global

צירוף שירות הקצה העורפי השני ל-MIG

gcloud compute backend-services add-backend YOUR_BACKEND_2 \
--project $PROJECT_ID --instance-group $MIG_NAME \
--instance-group-region $REGION \
--balancing-mode UTILIZATION --max-utilization 0.8 --global

רשימת מפת ה-URL ל-GCLB הקיים ב-Apigee

gcloud compute url-maps list -project $PROJECT_ID

איך מאתרים את השם הנכון של מפת URL שמשמשת לאיזון עומסים ב-Apigee

gcloud compute url-maps export APIGEE_URL_MAP_NAME -project $PROJECT_ID

יצירת קובץ YAML של מפת URL של איזון עומסים

אם כבר יש לכם מפת URL, צריך למזג את ההגדרה הזו לתוכו. אחרת, יוצרים קובץ YAML בנתיב /tmp/apigee-map.yaml עם ההגדרה הזו.

defaultService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_1
name: matcher1
routeRules:
- matchRules:
- headerMatches:
- headerName: Content-Type
prefixMatch: application/grpc
prefixMatch: /
priority: 100
routeAction:
weightedBackendServices:
- backendService: projects/dg-runtime-test1/global/backendServices/YOUR_BACKEND_2
weight: 100

החלת קובץ ה-YAML החדש לניתוב gRPC

gcloud compute url-maps import APIGEE_URL_MAP_NAME\
--source /tmp/apigee-map.yaml  \
--global -project $PROJECT_ID

הוספת אבטחה

כדי להשיג אבטחת פרוקסי, מוסיפים מדיניות לפרוקסי. מידע נוסף על מדיניות זמין במאמר מהי מדיניות. מידע נוסף על אבטחה זמין במאמר בנושא אבטחת שרת proxy.

כדי להוסיף מדיניות אבטחה לשרת ה-Proxy:

1. יוצרים שרת proxy כמו שמתואר במאמר יצירת שרת proxy ל-API.
2. מוסיפים מדיניות אבטחה כמו שמתואר באחד מהקטעים שמפורטים במאמר בנושא אבטחת שרת proxy. מדיניות האבטחה הנפוצה ביותר היא מפתחות API ו-OAuth2.

הוספת תמיכה ב-CORS

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

כדי להוסיף תמיכה ב-CORS, צריך להוסיף את מדיניות ה-CORS ל-request PreFlow של ProxyEndpoint.

למידע מפורט יותר על תמיכה ב-CORS, כולל הוספת תמיכה בבקשות CORS מסוג preflight לשרת proxy, ראו הוספת תמיכה ב-CORS ל-proxy ל-API.

הוספת מכסות

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

שימוש במפרטי OpenAPI כדי ליצור קובצי Proxy

בקטע הזה נסביר על האפשרות Use OpenAPI שזמינה ליצירה ממפרט OpenAPI של סוגי פרוקסי API הבאים: הפוך או ללא יעד.

מה זה מפרט OpenAPI?

   "The Open API Initiative (OAI) is focused on creating, evolving and promoting a vendor neutral API description format based on the Swagger Specification." מידע נוסף זמין באתר OpenAPI Initiative.

מפרט OpenAPI משתמש בפורמט סטנדרטי כדי לתאר API ל-REST. מפרט OpenAPI, שנכתב בפורמט JSON או YAML, הוא קריא למחשבים וגם קל לקריאה ולהבנה על ידי בני אדם. במפרט מתוארים רכיבי API כמו נתיב הבסיס, הנתיבים והפעלים, הכותרות, פרמטרים של שאילתות, פעולות, סוגי תוכן, תיאורי תגובות ועוד. בנוסף, נהוג להשתמש במפרט OpenAPI כדי ליצור תיעוד של API.

בקטע הבא ממפרט OpenAPI מתואר שירות היעד המדומה של Apigee,‏ http://mocktarget.apigee.net. מידע נוסף זמין במאמר מפרט OpenAPI לדוגמה helloworld.

openapi: 3.0.0
info:
  description: OpenAPI Specification for the Apigee mock target service endpoint.
  version: 1.0.0
  title: Mock Target API
paths:
  /:
    get:
      summary: View personalized greeting
      operationId: View a personalized greeting
      description: View a personalized greeting for the specified or guest user.
      parameters:
        - name: user
          in: query
          description: Your user name.
          required: false
          schema:
            type: string
      responses:
        "200":
          description: Success
  /help:
    get:
      summary: Get help
      operationId: Get help
      description: View help information about available resources in HTML format.
      responses:
        "200":
          description: Success
...

באמצעות האשף Create Proxy (יצירת שרת proxy), אפשר לייבא מפרט OpenAPI ולהשתמש בו כדי ליצור proxy ל-API. אחרי שיוצרים את ה-proxy, אפשר להשתמש בממשק המשתמש של Apigee כדי לפתח אותו עוד יותר על ידי הוספת מדיניות, הטמעה של קוד בהתאמה אישית וכו' – בדיוק כמו כל proxy של Apigee.

יצירת proxy ל-API ממפרט OpenAPI

יוצרים שרתי proxy ל-API ממפרט OpenAPI. בכמה קליקים בלבד, תקבלו שרת proxy של API עם הנתיבים, הפרמטרים, זרימות מותנות ונקודות קצה של יעד שנוצרו באופן אוטומטי. אחר כך תוכלו להוסיף תכונות כמו אבטחת OAuth, הגבלת קצב של יצירת בקשות וקירור מטמון.

באשף Create Proxy, לוחצים על Use OpenAPI Spec ופועלים לפי ההוראות באשף כדי ליצור פרוקסי הפוך או פרוקסי ללא יעד ממפרט OpenAPI. פרטים נוספים זמינים במאמר יצירת פרוקסי ל-API ממפרט OpenAPI.

יצירת גרסה חדשה של proxy ל-API

כדי ליצור גרסה חדשה של שרת proxy ל-API, מבצעים את השלבים הבאים:

1. פותחים את ממשק המשתמש של Apigee.

במסוף Google Cloud , נכנסים לדף Apigee > Proxy development > API proxies.

מעבר לשרתי proxy ל-API

2. לוחצים על ה-proxy ל-API ברשימה שרוצים להעתיק.

3. לוחצים על הכרטיסייה פיתוח.

4. לוחצים על הכפתור שמירה ובוחרים באפשרות שמירה כגרסה חדשה.

גיבוי של proxy ל-API

אפשר לגבות שרת proxy קיים ל-API כקבוצה של קובצי XML בחבילת שרת proxy ל-API. אחרי הייצוא לחבילה, אפשר לייבא את ה-proxy ל-API ל-proxy חדש, כמו שמתואר במאמר ייבוא של proxy ל-API מחבילת proxy ל-API שמופיע קודם בקטע הזה. מידע נוסף זמין במאמר בנושא הורדת proxy ל-API.

יצירת proxy ל-API באמצעות ה-API

כדי ליצור proxy ל-API באמצעות ה-API, אפשר לעיין במאמר בנושא יצירת proxy ל-API.

מידע על שרתי proxy ללא יעד

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

תרחישים נפוצים לדוגמה

• אינטראקציה עם נתונים שמנוהלים על ידי Apigee: פרוקסי ללא יעד שימושי במקרים שבהם צריך רק לבצע אינטראקציה עם נתונים שמנוהלים על ידי Apigee, כמו נתונים שמאוחסנים במפת מפתח-ערך (KVM) או במטמון של Apigee. לדוגמה, אפשר להשתמש בשרת proxy ללא יעד כדי לאחזר נתונים, כמו נתוני סשן של משתמשים או נתוני הגדרה, מ-KVM. במקרה כזה, אין צורך להתקשר לשירות לקצה העורפי. כל מה שצריך הוא מדיניות של KeyValueMapOperations בזרימת ה-proxy. דוגמה נוספת: יכול להיות שתרצו שהמתקשר יבקש לנקות את המטמון. אפשר לעשות את זה באמצעות הפעלת המדיניות InvalidateCache, בלי צורך להתחבר ליעד.
• שימוש בממשקי API מדומים: אתם יכולים ליצור ממשקי API מדומים כדי לדמות את התנהגות ה-API לפני שהטמעת ה-Backend מסתיימת, וכך לאפשר את המשך פיתוח ה-Frontend באופן עצמאי. מידע נוסף על יצירת ממשקי API מדומים זמין במאמר OpenAPI Mock API Proxy.
• ניהול טוקנים: Apigee יכול להנפיק טוקנים של OAuthV2, ובדרך כלל זה נעשה באמצעות שרת proxy ללא יעד.
• בדיקת התנהגות המדיניות: שרת proxy ללא טירגוט יכול להיות שימושי כשרוצים לנסות מדיניות של Apigee כדי לבדוק את ההתנהגות שלה.