יצירת שרת 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 באמצעות YAML

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

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

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

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

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

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

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

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

קטגוריה	סוג	תיאור
תבנית כללית	שרת proxy הפוך (הכי נפוץ)	proxy ל-API שמנתב בקשות נכנסות לשירותי קצה עורפי קיימים של HTTP. יכול להיות API בפורמט JSON או XML. אפשר לעיין בקטע יצירת שרת proxy הפוך לשירות HTTP בהמשך המאמר.
	ללא יעד	‫proxy ל-API ללא קצה עורפי של API (no target). בדומה ליצירת שרת proxy הפוך לשירות HTTP שמתואר למעלה, רק שלא מציינים API קיים כשמגדירים את פרטי ה-API proxy.
	העלאת חבילת 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 Model Armor.
	שרת proxy עם מטמון סמנטי	שמירת תשובות במטמון לבקשות דומות, כדי לשפר את זמן התגובה ואת הקריאות ל-LLM. מידע נוסף זמין במאמר איך מתחילים להשתמש במדיניות שמירה במטמון סמנטי.
תבנית של מפרט OpenAPI	שרת proxy הפוך (הכי נפוץ)	יוצרים את ה-proxy ממפרט OpenAPI תקין. מידע נוסף על האפשרות הזו מופיע בהמשך הקטע במאמר בנושא שימוש במפרטי OpenAPI ליצירת שרתי proxy.
	ללא יעד	‫API proxy ללא קצה עורפי של API (no target). בדומה ליצירת שרת proxy הפוך לשירות HTTP שמתואר למעלה, רק שבמקרה הזה לא מציינים API קיים כשמגדירים את פרטי ה-API proxy.

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

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

‫Apigee יוצרת שרתי proxy הפוכים על סמך המידע הבא:

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

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

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

שדה	תיאור
שם	השם שמוצג עבור ה-API. צריך לציין תווים אלפאנומריים, מקף (-) או קו תחתון (_).
נתיב בסיסי	קטע URI שמופיע אחרי הכתובת http://[host] או https://[host] של שרת ה-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 באופן אוטומטי כששומרים אותו. כדי לפרוס מחדש את שרת ה-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 ל-gRPC API ב-Apigee:

• תמיכה בבקשות gRPC אונריות.
• אי אפשר להשתמש במדיניות שמשפיעה על מטען הייעודי (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 באפליקציות ושימוש בפקודות של gcloud CLI כדי ליצור ניתוב ל-gRPC.

כדי ליצור שרת proxy של gRPC API, קודם צריך להגדיר שרת יעד של gRPC (ראו יצירת TargetServers), ואז לציין את שרת היעד הזה כשיוצרים את שרת ה-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

דוגמאות לפקודות gcloud CLI ליצירת ניתוב לשרתי 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. מוסיפים קבוצות של מכונות מנוהלות (MIG) לשירות הקצה העורפי. בדוגמה הזו אנחנו משתמשים מחדש ב-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 לשרת proxy, אפשר לעיין במאמר הוספת תמיכה ב-CORS לשרת proxy של API.

הוספת מכסות

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

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

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

מה זה מפרט OpenAPI?

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