כלי פיתוח

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

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

שימוש בממשק המשתמש של Edge

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

בטבלה הבאה מוסבר איך לגשת לממשק המשתמש של Edge:

https://apigee.com/edge

http://ms-ip:9000

בממשק המשתמש של Edge אפשר:

• ליצור שרתי proxy ל-API על ידי עריכת קוד ומעקב אחרי זרימת הבקשות דרך שרתי ה-proxy.
• ליצור מוצרי API שמשלבים שרתי proxy לחשיפה לבקשות של לקוחות.
• ניהול אפליקציות של מפתחים ומפתחים.
• מגדירים את סביבות הבדיקה והייצור.
• הטמעת אפליקציות JavaScript ו-Node.js.

בתמונה הבאה מוצג עורך ה-proxy ל-API בממשק המשתמש, שבו אפשר להשתמש כדי ליצור ולהגדיר Proxy ל-API:

שימוש ב-Edge API

כדי לנהל את משאבי ה-API אפשר להשתמש ב-Edge API. ממשקי ה-API מספקים גם גישה ליכולות ברמה נמוכה שאינן חשופות ממשק משתמש.

לעיתים קרובות, נקודות הקצה ל-API משתמשות בנתונים שכוללים פרטי תצורה ומחייבות להעביר פרטי אימות, כמו שם משתמש וסיסמה, כדי לגשת אליהם. מעקב אחרי RESTful את העקרונות הבסיסיים, אפשר לקרוא ל-HTTP GET, POST, PUT DELETE בכל אחד ממשאבי ה-API.

לרשימה מלאה של ממשקי ה-API של Apigee Edge: חומר עזר בנושא API של Apigee Edge.

הסבר על בסיס ה-API של Edge נתיב

הנתיב שבו משתמשים בבקשות API משרשר את המחרוזת הבאה:

• נתיב בסיס שכולל את שם הארגון. מוצרים לדוגמה: https://api.enterprise.apigee.com/v1/organizations/org_name
• נקודת קצה (endpoint) שמצביעה למשאב Edge שאליו אתם ניגשים.

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

https://api.enterprise.apigee.com/v1/organizations/apibuilders

כדי לאחזר רשימה של שרתי proxy ל-API בארגון, צריך להפעיל את GET ב:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/apis

משאבים רבים בהיקף של סביבה. כברירת מחדל מסופקות שתי סביבות: מוצר לדוגמה, המטמון מוגדרות לפי סביבה. מטמון משותף שנקרא "mycache" כלול כברירת מחדל בכל סביבה.

אפשר להציג רשימת מטמון על ידי קריאה ל-GET במשאב המטמון באופן הבא:

https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/test/caches
https://api.enterprise.apigee.com/v1/organizations/apibuilders/environments/prod/caches

אימות גישה

עליכם לבצע אימות לשרת ה-API במהלך הקריאה לממשקי ה-API. אפשר לבצע אחת מהדרכים הבאות:

• OAuth2
• SAML
• אימות בסיסי (לא מומלץ)

בנוסף, Apigee ממליצה להשתמש באימות דו-שלבי, כפי שמתואר ב- הפעלה אימות דו-שלבי בחשבון Apigee שלכם.

מגבלות על Edge API

כל ארגון מוגבל לתעריפי הקריאות הבאים ל-Edge API:

• 10,000 שיחות לדקה לארגונים בתוכניות בתשלום
• 600 שיחות לדקה לארגוני ניסיון

קודי מצב HTTP 401 ו-403 לא נחשבים כחלק מהמגבלה הזו. כל הקריאות שחורגות מהטווח הזה המגבלות מחזירות קוד סטטוס 429 Too Many Requests.

טיפים לעבודה עם ממשקי API של Edge

בקטע הזה מתוארות כמה מהטכניקות שמאפשרות עבודה עם ממשקי ה-API של Edge. יותר קל.

קיצור של כתובות URL של בקשות

כשיוצרים את כתובת ה-URL של הבקשה לממשקי ה-API של Edge, אפשר להשתמש וקיצורים:

• /e = /environments
• /o = /organizations
• /r = /revisions

אם אתם משתמשים בקיצורים, אתם צריכים להשתמש בהם באופן עקבי. כלומר, קצרו את כל הרכיבים של נתיב ההמרות, כפי שצוין למעלה ואיור בדוגמה הבאה, או ללא. שימוש ברכיבים מלאים וגם ברכיבים מקוצרים באותו נתיב יגרום לשגיאה.

לדוגמה:

THIS:
https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/environments/prod/apis/helloworld/revisions/1/deployments
CAN BE MUCH SHORTER:
https://api.enterprise.apigee.com/v1/o/ahamilton-eval/e/prod/apis/helloworld/r/1/deployments

הפעלת פקודות curl

משתמשים בלקוח HTTP כדי לשלוח בקשות ל-API. דוגמאות רבות בתיעוד לספק בקשות API לדוגמה באמצעות curl, לקוח HTTP שנמצא בשימוש נרחב. אם צריך להתקין את curl, אפשר להוריד אותו מ: http://curl.haxx.se.

קריאות ל-API תומכות בדחיסת gzip מופעלת תשובות מדויקות. אם תגדירו את 'Accept-Encoding: gzip, deflate' בקריאות ל-API, כל תגובה שגדולה מ-1,024 בייטים מוחזרת בפורמט gzip.

עיצוב בקשות ותגובות של XML ו-JSON

כברירת מחדל, ה-Edge API מחזיר נתונים כ-JSON. לבקשות רבות, אפשר לקבל תגובה נשלחים בחזרה כ-XML. כדי לעשות את זה, צריך להגדיר את כותרת הבקשה של Accept לערך application/xml, כמו בדוגמה הבאה:

curl -H "Authorization: Bearer `get_token`" \
  -H "Accept: application/xml" \
  https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  | xmllint --format -

התגובה אמורה להיראות כך:

<List>
  <Item>SOAP-Message-Validation-1</Item>
  <Item>Spike-Arrest-1</Item>
  <Item>XML-to-JSON-1</Item>
</List>

שימו לב שבדוגמה הזו נעשה שימוש בפונקציה prettyprint כדי להציג את התוצאות על ידי הצמדת התשובה xmllint.

כלי השירות acurl לא תומך בכותרת Accept. כתוצאה מכך, אפשר יתקבלו רק תשובות בפורמט JSON דרך acurl.

כדי להשתמש ב-prettyprint לתשובת JSON, אפשר להשתמש בספריית Python json.tool:

curl https://api.enterprise.apigee.com/v1/organizations/ahamilton-eval/apis/helloworld/revisions/1/policies/ \
  -H "Accept: application/json" \
  -H "Authorization: Bearer `get_token`" \
  | python -m json.tool

הדוגמה הבאה ממחישה את התשובה:

[
  "SOAP-Message-Validation-1",
  "Spike-Arrest-1",
  "XML-to-JSON-1"
]

בפורמט XML אפשר להשתמש ב-xmllint:

curl https://ahamilton-eval-test.apigee.net/getstarted -u email_address | xmllint --format -

כשמפרסמים או PUT מטענים ייעודיים (payloads) ב-XML, צריך להשתמש בכותרת ה-HTTP Content-type:

acurl -H "Content-type:text/xml" -X POST -d \
'<XMLPayload>
 </XMLPayload> ' \
https://api.enterprise.apigee.com/v1/organizations/apifactory/apis -u email_address

סביבות פריסה

לכל ארגון שמשתמש ב-Apigee Edge כברירת מחדל יש לפחות שתי סביבות שבהן הוא יכול להשתמש כדי פיתוח, בדיקה ופריסה של ממשקי API: "test" ו-'prod'. שימוש באפשרות 'בדיקה' לפיתוח ולבדיקה ממשקי ה-API לפני שהם הופכים לזמינים לציבור. רק המפתחים הפנימיים שלך יכולים לגשת לממשקי API נפרס בסביבת הבדיקה. פורסים את ממשקי ה-API ב-prod להפוך אותם לציבוריים שזמינות למפתחי אפליקציות.

ניפוי באגים ובדיקה

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

נקודות נתונים עיקריות לשימוש בפתרון בעיות:

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

האיור הבא מציג תוצאות מעקב:

כל פעילות של נתוני מעקב מחולקת לשלבים העיקריים הבאים:

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