יצירת שרת 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 שמוצג למפתחים.

ה-proxy ל-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 או XML. בהמשך הקטע הזה מוסבר איך ליצור proxy הפוך לשירות HTTP.
	ללא יעד	proxy ל-API ללא קצה עורפי של API ('ללא יעד'). בדומה ליצירת שרת proxy הפוך לשירות HTTP שמתואר למעלה, רק שלא מציינים API קיים כשמגדירים את פרטי ה-proxy ל-API.
	העלאת חבילת proxy	חבילת proxy ל-API קיימת (לדוגמה, אחת מהדוגמאות ל-proxy ל-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 בענן) או שהם יכולים להיות ממשק API או שירות של צד שלישי (לדוגמה, Twitter או Instagram).

אחרי שמגיעים אל האשף ליצירת שרת 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, יחד עם קובצי תמיכה אחרים. אם מגדירים את פרוקסי ה-API כקבוצה של קבצים חיצוניים ל-Apigee, אפשר לתחזק אותם במערכת בקרת מקור, ואז לייבא אותם ל-Apigee לצורך בדיקה ופריסה.

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

1. ניגשים לאשף Create Proxy (יצירת שרת proxy) כמו שמתואר במאמר יצירת שרת proxy ל-API באמצעות ממשק המשתמש.
2. מציינים את פרטי חבילת שרת ה-proxy ל-API.
1. בתפריט Proxy template (תבנית שרת Proxy), בוחרים באפשרות Upload proxy bundle (העלאת חבילת שרת 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 unary.
• אי אפשר להשתמש במדיניות שמשפיעה על מטען הייעודי (payload).
• אפשר להשתמש בו במוצרי API שלא משויכים ל-GraphQL או לשרתי proxy של REST. מכסות ספציפיות למוצר של API והגדרות פעולה אחרות חלות על כל ה-proxies במוצר.
• לא נתמכות ב-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 (ראו יצירת TargetServers), ואז לציין את שרת היעד הזה כשיוצרים את ה-proxy החדש.

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

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

הקטע הזה לא נועד להיות מדריך מקיף ליצירת ניתוב. יכול להיות שהדוגמאות האלה לא מתאימות לכל תרחישי השימוש. בנוסף, ההוראות האלה מניחות שאתם מכירים את הניתוב החיצוני (MIG) ואת ההגדרה של 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

צירוף שירות ה-Backend השני ל-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 לשרת proxy, אפשר לעיין במאמר הוספת תמיכה ב-CORS ל-proxy ל-API.

הוספת מכסות

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

שימוש במפרטי OpenAPI כדי ליצור שרתי proxy

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

מה זה מפרט OpenAPI?

   "ה-Open API Initiative‏ (OAI) מתמקד ביצירה, בפיתוח ובקידום של פורמט ניטרלי לספק לתיאור API, שמבוסס על מפרט Swagger". מידע נוסף זמין במאמר בנושא 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. אחרי שהפרוקסי נוצר, אפשר להשתמש בממשק המשתמש של Apigee כדי לפתח אותו עוד יותר על ידי הוספת מדיניות, הטמעה של קוד בהתאמה אישית וכו' – בדיוק כמו כל פרוקסי של Apigee.

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

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

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

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

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

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

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

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

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

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 לפני שהטמעת ה-בק-אנד הושלמה, וכך לאפשר את המשך ה-פיתוח של ה-קצה קדמי באופן עצמאי. מידע נוסף על יצירת ממשקי API מדומים זמין במאמר OpenAPI Mock API Proxy.
• ניהול טוקנים: Apigee יכול להנפיק טוקנים של OAuthV2, ובדרך כלל זה נעשה באמצעות שרת proxy ללא יעד.
• בדיקת התנהגות המדיניות: שרת proxy ללא טירגוט יכול להיות שימושי כשרוצים לנסות מדיניות של Apigee כדי לבדוק את ההתנהגות שלה.