מבוא
עם כמה קליקים על שולחן עבודה או מכשיר, אפשר לקנות, למכור או לפרסם כל דבר, בכל עת. איך זה קורה בדיוק? איך מידע להגיע מפה לשם? הגיבור הלא מוכר הוא ה-API.
מהו ממשק API?
API מייצג an ממשק תכנות יישומים. API מבטא רכיב תוכנה, פעולותיו, התשומות, הפלטים והסוגים הבסיסיים שלו. אבל איך אתה מסביר את ה-API באנגלית פשוטה? ה-API מתפקד כשליח שמעביר את הבקשה שלך מאפליקציה ומחזיר לך את התגובה.
דוגמא 1: כשאתה מחפש טיסות באינטרנט. אתה מקיים אינטראקציה עם אתר האינטרנט של חברת התעופה. האתר מפרט את מקומות הישיבה ועלות הטיסה בתאריך ובשעה המסוימים. אתה בוחר את בקשות הארוחה או הישיבה, המטען או חיית המחמד שלך.
אבל, אם אינך משתמש באתר הישיר של חברת התעופה או ומשתמש בסוכן נסיעות מקוון המשלב נתונים מחברות תעופה רבות. כדי לקבל את המידע, אפליקציה מקיימת אינטראקציה עם ה-API של חברת התעופה. ה-API הוא הממשק שלוקח נתונים מאתר סוכן הנסיעות למערכת של חברת התעופה.
זה גם מקבל את תגובת חברת התעופה ומחזיר מיד. זה מקל על האינטראקציה בין שירות הנסיעות לבין מערכות חברת התעופה - להזמנת הטיסה. ממשקי API כוללים ספריה לשגרות, מבני נתונים, מחלקות אובייקט ומשתנים. לדוגמה, שירותי SOAP ו-REST.
דוגמא 2: Best Buy הופכת את תמחור עסקת היום לזמינה דרך האתר שלה. אותם נתונים נמצאים באפליקציה הסלולרית שלו. האפליקציה לא דואגת למערכת התמחור הפנימית - היא יכולה להתקשר ל-API של Deal of the Day ולשאול, מה התמחור המיוחד? Best Buy מגיבה עם המידע המבוקש בפורמט סטנדרטי שהאפליקציה מציגה למשתמש הקצה.
דוגמה XNXX: ממשקי API עבור מדיה חברתית הם קריטיים. משתמשים יכולים לגשת לתוכן ולשמור על מספר החשבונות והסיסמאות שהם עוקבים אחריהם נמוך, כך שהם יכולים לשמור על דברים פשוטים.
- API של Twitter: אינטראקציה עם רוב הפונקציות של Twitter
- Facebook API: לתשלומים, נתוני משתמש וכניסה
- ממשק API של אינסטגרם: תייגו משתמשים, צפו בתמונות טרנדיות
מה לגבי REST & SOAP API's?
סבון ו REST השתמש בשירות שצורך API, המכונה Web API. שירות האינטרנט אינו תלוי בידע מוקדם כלשהו במידע. SOAP הוא פרוטוקול שירות אינטרנט שאינו תלוי בפלטפורמה קלת משקל. SOAP הוא פרוטוקול הודעות מבוסס XML. בניגוד לשירות האינטרנט SOAP, שירות Restful משתמש בארכיטקטורת REST, שנבנתה לתקשורת מנקודה לנקודה.
שירות אינטרנט SOAP
- SOAP Sender – יצירה והעברת הודעה.
- מקלט SOAP – משיג ומעבד את ההודעה.
- SOAP Intermediary- מקבל ומעבד בלוקים של כותרות.
שירות אינטרנט RESTful
העברת מצב ייצוגית (REST) מתייחסת ליחסים בין הלקוח לשרת ולאופן שבו המצב מעבד. ארכיטקטורת מנוחה, שרת REST מספק גישה למשאבים ללקוח. Rest מטפל בקריאה ובשינוי או כתיבה של המשאבים. מזהה אחיד (URI) מזהה משאבים להכיל מסמך. זה יתפוס את מצב המשאב.
REST קל יותר מארכיטקטורת SOAP. הוא מנתח את JSON, שפה הניתנת לקריאה על ידי אדם המאפשרת שיתוף נתונים וקל יותר לשימוש בנתונים, במקום XML המשמש את ארכיטקטורת SOAP.
ישנם מספר עקרונות לעיצוב Restful Web Service, שהם:
- יכולת כתובת - לכל משאב צריכה להיות כתובת URL אחת לפחות.
- חוסר אזרחות - שירות נח הוא שירות חסר אזרחות. בקשה אינה תלויה בבקשות קודמות של השירות. HTTP הוא בעיצובו פרוטוקול חסר מצב.
- ניתן למטמון - נתונים מסומנים כמאגרים ניתנים למטמון במערכת ושימוש חוזר בעתיד. כמענה לאותה בקשה במקום לייצר את אותן תוצאות. אילוצי מטמון מאפשרים סימון נתוני תגובה כניתנים למטמון או שאינם ניתנים לאחסון במטמון.
- ממשק אחיד - מאפשר שימוש בממשק נפוץ וסטנדרטי לצורך גישה. השימוש באוסף מוגדר של שיטות HTTP. עמידה במושגים הללו מבטיחה שהטמעת REST היא קלת משקל.
היתרונות של REST
- משתמש בפורמט פשוט יותר עבור הודעות
- מציע יעילות חזקה יותר לטווח ארוך
- זה תומך בתקשורת חסרת מדינה
- השתמש בתקני HTTP ובדקדוק
- הנתונים זמינים כמשאב
חסרונות של REST
- נכשל בסטנדרטים של שירות אינטרנט כגון עסקאות אבטחה וכו'.
- בקשות REST אינן ניתנות להרחבה
השוואת מנוחה לעומת סבון
הבדלים בין שירותי האינטרנט SOAP ו-REST.
שירות האינטרנט SOAP | Rest Web Service |
דורש מטען קלט כבד בהשוואה ל-REST. | REST הוא קל משקל מכיוון שהוא משתמש ב-URI עבור טפסי נתונים. |
שינוי בשירותי SOAP מוביל לרוב לשינוי משמעותי בקוד בצד הלקוח. | קוד בצד הלקוח אינו מושפע משינוי בשירותים בהקצאת אינטרנט של REST. |
סוג החזרה הוא תמיד מסוג XML. | מספק צדדיות ביחס לצורת הנתונים המוחזרים. |
פרוטוקול הודעות מבוסס XML | פרוטוקול אדריכלי |
דורש ספריית SOAP בקצה הלקוח. | אין צורך בתמיכה בספרייה בדרך כלל בשימוש ב-HTTP. |
תומך ב-WS-Security ו-SSL. | תומך ב-SSL ו-HTTPS. |
SOAP מגדירה את האבטחה שלה. | שירותי אינטרנט RESTful יורשים אמצעי אבטחה מהתחבורה הבסיסית. |
סוגי מדיניות שחרור API
מדיניות שחרור עבור API היא:
מדיניות שחרור פרטית:
ה-API זמין רק לשימוש פנימי בחברה.
מדיניות שחרור של שותפים:
ה-API זמין רק עבור שותפים עסקיים מסוימים. החברות יכולות לשלוט באיכות ה-API בגלל השליטה על מי שיכול לגשת אליו.
מדיניות פרסום לציבור:
ה-API מיועד לשימוש ציבורי. הזמינות של מדיניות השחרור זמינה לציבור. דוגמה: Microsoft Windows API ו-Cocoa של אפל.
סיכום
ממשקי API קיימים בכל מקום, בין אם אתה מזמין טיסה או עוסק ביישומי מדיה חברתית. SOAP API מבוסס על תקשורת XML, הוא שונה מ-REST API בכך שהוא אינו דורש שום תצורה מיוחדת.
עיצוב שירותי אינטרנט של Rest צריך לעמוד במושגים מסוימים, כולל יכולת כתובת, חוסר מצב, יכולת מטמון וממשק סטנדרטי. ניתן לחלק כללי שחרור API לשלוש קטגוריות: ממשקי API פרטיים, ממשקי API של שותפים וממשקי API ציבוריים.
תודה שקראת את המאמר הזה. עיין במאמר שלנו על מדריך ל אבטחת API 2022.
