מהו API? הסבר על ממשקי תכנות יישומים

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

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

מהו API?

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

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

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

API כשכבת הפשטה

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

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

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

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

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

ממשקי API ציבוריים ושילוב API

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

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

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

שירותי אינטרנט ו- API

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

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

ממשקי API של REST

שירותי רשת תוכננו במקור לתקשר באמצעות SOAP (Simple Object Access Protocol), פרוטוקול העברת הודעות השולח מסמכי XML דרך HTTP. אולם כיום, רוב ממשקי ה- API מבוססי האינטרנט משתמשים ב- REST - העברת מדינות ייצוגיות - כסגנון אדריכלי.

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

ב- API של REST, משאב יכול להיות כמעט כל דבר, אך דוגמאות כוללות משתמש, רשימת ציוצים והתוצאות הנוכחיות של חיפוש אחר ציוצים. ניתן להתייחס לכל אחד מהמשאבים הללו במזהה משאבים , שבמקרה של ממשקי API של REST מבוססי אינטרנט הוא בדרך כלל כתובת URL, כגון //api.twitter.com/1.1/users/show?screen_name=twitterdev כאשר יישום מבקש משאב באמצעות המזהה, ה- API מספק את הייצוג הנוכחי של אותו משאב ליישום בתבנית שהיישום יכול לצרוך, כגון תמונת JPEG, עמוד HTML או JSON.

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

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

דוגמאות API

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

  • ממשקי API של גוגל , המאפשרים לך לחבר את הקוד שלך לכל מגוון שירותי Google, ממפות ל- Translate. ממשקי API כל כך חשובים לגוגל שהם רכשו את Apigee, פלטפורמת ניהול API מובילה.
  • ממשקי API של פייסבוק , המאפשרים לך לגשת באופן פרוגרמטי לגרף החברתי ולכלי השיווק של פייסבוק. (החברה הגבילה בדיוק את נתוני המשתמשים אליהם אתה יכול לגשת דרך ממשקי ה- API הללו במהלך הנפילה מקיימברידג 'אנליטיקה ושערוריות אחרות.)

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

ממשק ה- API של Java

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

ממשק ה- API של טוויטר

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

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

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

תכנון API

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

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

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

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