מהו API? באנגלית בבקשה.

לפני שלמדתי פיתוח תוכנה, API נשמע כמו סוג של בירה.

היום אני משתמש במונח לעתים קרובות כל כך שלמעשה לאחרונה ניסיתי להזמין API בבר.

תגובת הברמן הייתה לזרוק 404: משאב לא נמצא.

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

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

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

WWW ושרתים מרוחקים

כשאני חושב על האינטרנט, אני מדמיין רשת גדולה של שרתים מחוברים .

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

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

כשאתה מקליד www.facebook.com בדפדפן שלך, בקשה יוצאת לשרת המרוחק של פייסבוק. לאחר שהדפדפן שלך מקבל את התגובה, הוא מפרש את הקוד ומציג את הדף.

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

ממשק API אינו זהה לשרת המרוחק - אלא הוא חלק השרת שמקבל בקשות ושולח תגובות .

ממשקי API כדרך לשרת את הלקוחות שלך

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

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

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

לחלופין, הדפדפן שלך יכול לעתים קרובות לשלוח בקשת API ישירות לשרת של גוגל ועוקף את השרת שלך.

במה שונה ה- API של יומן Google זה מממשק ה- API של כל שרת מרוחק אחר שם?

במונחים טכניים ההבדל הוא פורמט הבקשה והתגובה.

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

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

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

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

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

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

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

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

לדוגמה, אתה יכול לגשת לממשק ה- API של GitHub ישירות באמצעות הדפדפן שלך מבלי להזדקק לאסימון גישה. הנה תגובת JSON שתקבל כאשר אתה מבקר במסלול ה- API של משתמש GitHub בדפדפן שלך (//api.github.com/users/petrgazarov):

{ "login": "petrgazarov", "id": 5581195, "avatar_url": "//avatars.githubusercontent.com/u/5581195?v=3", "gravatar_id": "", "url": "//api.github.com/users/petrgazarov", "html_url": "//github.com/petrgazarov", "followers_url": "//api.github.com/users/petrgazarov/followers", "following_url": "//api.github.com/users/petrgazarov/following{/other_user}", "gists_url": "//api.github.com/users/petrgazarov/gists{/gist_id}", "starred_url": "//api.github.com/users/petrgazarov/starred{/owner}{/repo}", "subscriptions_url": "//api.github.com/users/petrgazarov/subscriptions", "organizations_url": "//api.github.com/users/petrgazarov/orgs", "repos_url": "//api.github.com/users/petrgazarov/repos", "events_url": "//api.github.com/users/petrgazarov/events{/privacy}", "received_events_url": "//api.github.com/users/petrgazarov/received_events", "type": "User", "site_admin": false, "name": "Petr Gazarov", "company": "PolicyGenius", "blog": "//petrgazarov.com/", "location": "NYC", "email": "[email protected]", "hireable": null, "bio": null, "public_repos": 23, "public_gists": 0, "followers": 7, "following": 14, "created_at": "2013-10-01T00:33:23Z", "updated_at": "2016-08-02T05:44:01Z"}

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

A מיועד ל"יישום "

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

"יישום" יכול להתייחס לדברים רבים. הנה כמה מהם בהקשר של API:

1. פיסת תוכנה עם פונקציה מובחנת.
2. כל השרת, כל האפליקציה, או רק חלק קטן מאפליקציה.

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

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

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

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

לאובייקט יכול להיות גם היגיון פנימי שהוא פרטי, כלומר שהואמוּסתָרמההיקף החיצוני (ולא ממשק API).

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

משאבים מעניינים (דברים שהשארתי אבל עדיין מגניב מאוד):

סרטון יוטיוב נהדר ב- DNS (מערכת שמות מתחם)

יסודות פרוטוקול HTTP

סרטון אקדמיית חאן מדהים על עקרונות עיצוב מונחים עצמים