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

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

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

אפיון API

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

ראשית, API יכול לשמש למספר מטרות:

1. API יכול לקשר בין מערכות שונות בתוך הארגון.
2. API יכול לאפשר לשותפים מחוץ לארגון לשלוח פקודות ולקבל מידע מבסיסי נתונים ומערכות בארגון.
3. API יכול לאפשר למשתמשי קצה – משתמשים מחוץ לארגון שאינם בהכרח מוכרים לארגון – לבצע פעולות מול מערכות התוכנה של הארגון.

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

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

סוגי API

ישנם 2 סוגי API עיקריים מהם נבחר את סוג ה API שרלוונטי לנו כבר בשלב האפיון:

1. RESTful API
2. SOAP

RESTful API הוא מודרני יותר, מבוסס HTTP ולכן קל יותר ומהיר יותר ליישום למתכנתים שיעשו בו שימוש.

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

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

Webhooks (Reverse API)

בעוד ש REST ו SOAP הם ממשקים דו כיווניים, Webhook היא דרך נוספת, קלה ופשוטה יותר לקשר בין מערכות. ההבדל העיקרי בין API ל Webhook הוא ש-API מבוסס על בקשות (קריאות) שנעשות ל-API מבחוץ, ואילו Webhook מבוסס על אירועים, כלומר הפעולה מתבצעת ללא קריאה מבחוץ.

לדוגמה, אם נרצה שמערכת CRM תשלח הודעה בזמן אמת למערכת דיוור בכל פעם שמתווסף לקוח חדש ל-CRM: ממשק ה-CRM יהיה Webhook והממשק של מערכת הדיוור (זו שמקבלת את הקריאה) יהיה API מסוג REST או SOAP.

היתרונות של עבודה עם API

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

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

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

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

• רמות הרשאה – כל משתמש שיתחבר ל-API יהיה תחת רמת הרשאה שונה ויהיה חשוף לנתונים שונים. לדוגמה חלק מהמשתמשים יוכלו לקבל הרשאה לעדכון נתונים ואחרים יקבלו הרשאת צפיה בלבד בנתונים.
• הגבלת פעילות (Throttling) – אפשר להגביל את ה-API למספר קריאות בפרק זמן נתון. לדוגמה אם לקוח מנסה לקרוא ל-API יותר מ 5 פעמים בשנייה תחילה קצב הגישה שלו יואט ולאחר מכן הוא יחסם למספר דקות.
• ניטור – קל מאד לנטר API. אם ה-API לא באוויר או קיימת בעיה כלשהי ישלחו התראות מיידיות למנהלים במייל או SMS, או התראות אוטומטיות כגון Webhooks למערכות אחרות.
• אבטחת מידע – ה-API הוא מעין שכבת הגנה על הנתונים לכן ארגון שצריך לתמוך בתקנים כגון ISO27001, HIPPA, GDPR יעדיף לעטוף את הגישה לנתונים באמצעות API. עבור חברות אבטחת מידע ביצוע מבדקי חדירות (penetration tests) ל-API הוא הליך סטנדרטי. למפתחים, שיפורים שוטפים באבטחת המידע בשכבת ה-API יהיו קלים יחסית ליישום.
• ריבוי אינטגרציות – API משרת מספר מערכות שונות במקביל. לכן לאחר פיתוח API עבור מערכת מסויימת, הארגון רוכש יכולת שתאפשר לו לחבר לאותו ה-API מערכות נוספות מבלי לפתח קוד חדש.
• טיפול מרכזי בהודעות שגיאה – לוג של API מסייע למנהל מערכות המידע בארגון לקבל תמונה ברורה ועדכנית במקום אחד מרכזי מבלי לעבור על קבצי לוג של מספר מערכות בכדי לאתר בעיה בודדת.
• סטנדרטיזציה – ארגון שמתחזק API מאגד תהליכים דומים במקום מרכזי אחד ולכן מונע מצב שבו ממחלקות שונות בארגון מפתחות 'פתרונות נקודתיים' כל אחת לעצמה. לאורך זמן תחזוקה של API מרכזי תהיה זולה יותר ויעילה יותר מאלטרנטיבות אחרות.
• תיעוד – תיעוד הממשק במקום מרכזי מאפשרת לשמר את הידע בארגון לאורך זמן וחוסך במשאבים כאשר שותפים חדשים מתחברים ל-API. כלים ייעודיים כגון Swagger מאפשרים תיעוד אונליין של ה-API בנוסף לבדיקות אוטומטיות וקטעי קוד אוטמטיים שמיוצרים עבור המתכנתים לבדיקת ה-API.

למה כדאי לפתח API עם imoon

• ניסיון בפיתוח ממשקי API מעל ל 15 שנים
• ממשקי ה-API שפיתחנו משרתים משרדי ממשלה וגופים מסחריים גדולים
• ניסיון בפיתוח ממשקי API מכל הסוגים – REST, SOAP, Webhooks
• ניסיון בפיתוח ממשקי API שעוברות דרכם מיליוני קריאות ביום
• חיבור ממשק ה-API ל Zapier & Integromat
• צוות המתכנתים שלנו מישראל
• ליווי צמוד גם לאחר סיום הפיתוח

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