Basic terminology

ממשק תכנות יישומים – ממשק שעוזר לאפליקציה אחת לצרוך יכולות או נתונים מאפליקציה אחרת בקלות.

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

ב-Apigee יש שפע של מידע על ממשקי API ועל שיטות מומלצות לפיתוח ולצריכה שלהם. כדי להתחיל, עיינו בשידור האינטרנט של API Design או הורידו בחינם את הספר האלקטרוני Web API Design: The missing Link Best Practices forcrafting Interfaces שמפתחים אוהבים.

חזית ב-Edge ב-Edge עבור ממשק API אחד או יותר, שירותי HTTP כלליים או אפליקציות (כמו Node.js).

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

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

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

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

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

מפתח API מקושר למוצר אחד או יותר של API, ואכיפת הקישור בין האפליקציה לבין חבילת מזהי ה-URI שהאפליקציה מורשית להשתמש בה.

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

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

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

• סביבת הבדיקה משמשת בדרך כלל לפריסת שרתי proxy של API במהלך הפיתוח.
• הסביבה prod משמשת בדרך כלל לקידום שרתי proxy של API מסביבת הבדיקה, אחרי שהם פותחו ונבדקו במלואם.

מאגר של כל האובייקטים בחשבון Apigee Edge, כולל שרתי proxy של API, מוצרי API, חבילות API, אפליקציות ומפתחים.

יש צורך בחשבון משתמש לכל ארגון שבו אתם חברים. (לרוב המשתמשים יהיה חשבון בארגון אחד בלבד).

שלב בעיבוד שמופעל כיחידת לוגיקה אטומית לשימוש חוזר בתהליך עיבוד של שרת proxy ל-API.

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

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

הגרסה של ממשק ה-API למפתחים.

לדוגמה, pivotaltracker.com/services/v3 או api.enterprise.apigee.com/v1.

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