האם אתה רוצה לקשר את האפליקציה שלך לפייסבוק כדי שתוכל ליצור פוסטים באופן אוטומטי, או לאינסטגרם כדי שתוכל לפרסם מחדש תמונות עם האשטאגים מסוימים?
תוכל גם לרצות לכלול סרטוני YouTube באתר האינטרנט שלך. ממשקי תכנות יישומים מאפשרים לך לבצע את כל המשימות הללו ועוד (API).
יישומים שונים יכולים "לדבר" אחד עם השני בצורה מאובטחת וסטנדרטית הודות לממשקי API כמו אינסטגרם API, Facebook API ו-YouTube API.
במילים אחרות, תוכנית יכולה לקחת תכונות או נתונים מתוכנה אחרת ולהשתמש בהם כדי לשפר את התכונות או חווית המשתמש שלה. אבל איך אפליקציות יכולות לבקש את הבקשות האלה, לעבד אותן ולהגיב להן בצורה שאחרים יכולים להבין?
זה תלוי איך ה-API נוצר. כאשר דנים בעיצובי API (ממשק תכנות יישומים), נהוג להשוות SOAP לעומת REST, שתיים מהפרדיגמות הבולטות של API.
ברגע שממשקי SOAP API (Simple Object Access Protocol) הפכו לסטנדרט הזהב עבור חברות כמו אורקל, סאן ו-PayPal, הייתה תגובה שווה והפוכה כעבור שנה בערך כלפי REST APIs מגוגל, אמזון ואיביי.
בפוסט זה נשווה ונשווה את ממשקי SOAP עם ממשקי API של REST כדי שתוכל להחליט מה הכי מתאים למטרות שלך.
נתחיל בהגדרת ה-API.
מה זה API?
ממשק תכנות יישומים מכונה API. ממשקי API הם בעצם אוסף של שיטות ופונקציות המאפשרות פיתוח אפליקציות. הם מקבלים גישה למידע ולפונקציות של תוכניות, שירותים או מערכות הפעלה שונות.
הם משמשים מעין מתווך בין מערכות תוכנה שונות. הם מאפשרים "דיבור" בין שתי תוכניות לא מחוברות.
ניקח דוגמה של סוכן מניות שמעורב באופן פעיל במסחר ובשווקים הפיננסיים. אוסף של אוטומטיות אלגוריתמי מסחר ניתן לחבר לפלטפורמת ברוקר המסחר המועדף על הסוחר באמצעות API. זה מאפשר לך, הסוחר, לבצע עסקאות אלקטרוניות או לראות הצעות מחיר ונתוני תמחור בזמן אמת.
מה זה REST?
ממשקי API אמיתיים של "שירותי אינטרנט" כוללים REST (העברת מדינה ייצוגית). ממשקי API של REST בנויים על URIs (מזהי משאבים אחידים, שכתובת URL היא מסוג מיוחד מהם), פרוטוקול HTTP ופורמט הנתונים JSON תואם הדפדפן להפליא.
פרוטוקול SOAP, כפי שכבר ציינו, עשוי לשמש גם כן. ממשקי API של REST יכולים להיות קלים ליצירה ולגידול, אבל הם יכולים גם להיות עצומים וקשים - הכל תלוי איך הם נוצרים, מורחבים ומה הם נועדו לעשות.
אילוצי משאבים, דרישות אבטחה מופחתות, תאימות ללקוח הדפדפן, יכולת גילוי, תקינות נתונים ומדרגיות הן כמה סיבות שהיית רוצה לפתח API כדי להיות RESTful - דברים שחלים בפועל על שירותי אינטרנט.
REST מציע אפשרות קלת משקל יותר. SOAP היה קשה לשימוש והעיק על מפתחים רבים. לדוגמה, שימוש ב-SOAP עם JavaScript מצריך כתיבת קוד רב כדי להשלים פעולות פשוטות שכן יש ליצור את מבנה ה-XML הדרוש בכל פעם.
REST (בדרך כלל) משתמש בכתובת URL פשוטה במקום בקשת XML. למרות שישנן נסיבות נדירות שבהן עליך להציע פרטים נוספים, רוב שירותי האינטרנט של RESTful משתמשים רק בטכניקת URL.
ארבעת הפעלים של HTTP 1.1 GET, POST, PUT ו-DELETE יכולים לשמש על ידי REST לביצוע פעולות. שלא כמו SOAP, REST לא צריך שהתשובה תהיה ב-XML.
שירותי אינטרנט מבוססי REST המפלטים נתונים בפורמטים של Command Separated Value (CSV), סימון אובייקט JavaScript (JSON) ו- Really Simple Syndication (RSS) זמינים (RSS).
המטרה היא שתוכל לקבל את התוצאות הדרושות לך בפורמט קל לניתוח בשפה שבה אתה משתמש עבור היישום שלך.
תכונות
- REST מדגיש את הפשטות מעל הכל, הודות לפרוטוקולי HTTP.
- הרשת מתאימה ביותר ל-REST. זה תואם לדפדפנים מכיוון ש-JSON משמש כפורמט הנתונים.
- REST ידועה במדרגיות ובמהירות יוצאי דופן.
- חיבורי שרת-לקוח וארכיטקטורות הופכים לנגישים יותר על ידי ממשקי API של REST. אם הוא RESTful, הוא נבנה באמצעות מודל שרת-לקוח זה, עם נסיעות הלוך ושוב בין שני הצדדים המעבירים עומסי נתונים.
- ממשקי API של REST משתמשים בממשק סטנדרטי בודד. הבטחת שכל היישומים מתחברים באופן אחיד ודרך אותו שער, מייעלת את האופן שבו יישומים מתקשרים עם ה-API.
מה זה סבון?
הפרוטוקול שלו, הנקרא SOAP (Simple Object Access Protocol), הוא קצת יותר מסובך מ-REST מכיוון שהוא מציין יותר תקנים, כולל אלה הקשורים לאבטחה ומשלוח הודעות.
הנורמות האינהרנטיות הללו מגיעות עם תקורה קטנה נוספת. עם זאת, הם יכולים להוות גורם מכריע עבור עסקים הזקוקים ליכולות תאימות נרחבות יותר של אבטחה, עסקאות ו-ACID (אטומיות, עקביות, בידוד, עמידות).
לצורך השוואה זו, חשוב לציין שרבים מהיתרונות של SOAP אינם חלים לעתים קרובות על יישומי שירותי אינטרנט, מה שהופך אותם למתאימים יותר לתרחישים מסוג ארגוני.
דרגות אבטחה גבוהות יותר (כגון כאשר א Mobile App אינטראקציה עם בנק), אפליקציות הודעות הדורשות תקשורת מהימנה, אינטראקציה עם מערכות מדור קודם או תאימות ל-ACID הן כמה סיבות שתרצו לעצב אפליקציה באמצעות SOAP API.
יכולות העברת ההודעות שמציעה SOAP מבוססות לחלוטין על XML. טכנולוגיות ישנות יותר שאינן תואמות לאינטרנט, כמו מודל אובייקטים מבוזרים (DCOM) ו-Common Object Request Broker Architecture הוחלפו ב-SOAP כאשר היא נוצרה לראשונה על ידי מיקרוסופט (CORBA).
ההסתמכות על תקשורת בינארית גורמת לכשל של מערכות אלו. דרך האינטרנט, הודעות XML כמו זו המשמשות את SOAP מתפקדות טוב יותר.
תכונות
- האבטחה של SOAP הדוקה משמעותית. WS-Security הוא תקן מובנה המציע SOAP יכולות אבטחה נוספות ברמת הארגון במידת הצורך בנוסף לתמיכה ב-SSL.
- נימוק מוצלח/נסה שוב לביצועי הודעות מהימנות. מכיוון ש-REST חסר מנגנון הודעות סטנדרטי, הוא יכול לנסות שוב רק כאשר התקשורת נכשלת. גם כאשר משתמשים בתוצרי ביניים של SOAP, SOAP מציעה אמינות מקצה לקצה הודות להיגיון המובנה של מוצלח/ניסיון חוזר.
- SOAP כבר תואם לתקני ACID. על ידי הכתבה כיצד עסקאות יכולות לקיים אינטראקציה עם מסד הנתונים, תאימות ACID ממזערת חריגות ושומרת על עקביות מסד הנתונים. מכיוון ש-ACID זהיר יותר ממודלים אחרים של עקביות נתונים, הוא משמש לעתים קרובות בעת ניהול עסקאות רגישות, בין אם פיננסיות או אחרות.
- זה פשוט למתכנתים להבין שכן SOAP היא תקשורת מבוססת XML לחלוטין.
- פרוטוקול הודעות XML הוא תוספת לפרוטוקול HTTP.
- ניתן להפיץ תקשורת ממחשב אחד למחשב אחר באמצעות הודעות SOAP.
- ניתן ליישם גם ארכיטקטורת שרת-לקוח. הודעת פרוטוקול SOAP יכולה לשמש את הלקוח כדי לקרוא לקריאת פרוצדורה מרחוק שנמצאת בצד השרת.
הבדלים של מנוחה לעומת סבון
1. אדריכלות
API נועד בעיקר להציג רכיבים ספציפיים של ההיגיון העסקי של אפליקציה בשרת. בעוד REST עושה שימוש ב-URI לאותה מטרה, SOAP משתמש בממשק שירות לשם כך.
ממשקי API של REST נוצרים לאחר הנתונים, ואילו ממשקי SOAP מפותחים לאחר הפונקציונליות שה-API ממחיש. בהשוואה ל-SOAP, שהוא יותר מונע פונקציות, REST הוא עיצוב יותר מונע נתונים.
2. מטמון
דפדפנים יכולים להשתמש בנתונים שסומנו כניתנים למטמון שוב מבלי לדרוש מהם להגיש בקשה חדשה לשרת. חיסכון בזמן ובמאמץ הוא יתרון בכך.
תגובות לא יישמרו במטמון ברמת HTTP מאחר שאילתות SOAP נשלחות באמצעות בקשות POST, שתקן ה-HTTP מחשיב כבלתי-אימפוטנטיות. אם ברצונך להשתמש במטמון, עדיין עליך לבנות את הטכניקות הדרושות מכיוון שממשקי API של REST אינם כוללים יישום זה.
3. משאבים ורוחב פס
בשל העברת המטען בסגנון המעטפת המשמשת את SOAP, ישנה עלייה מתונה בתקורה, מה שמחייב רוחב פס נוסף. האופי הקל משקל של REST הוא יתרון במצבים אלה מכיוון שהוא משמש בדרך כלל עבור שירותי אינטרנט.
4. ביטחון
רצוי WS-security, אשר SOAP תומך בו והוא מעט יותר יסודי מ-SSL ברמת התחבורה. שילוב אמצעי אבטחה ברמת הארגון איתו הוא גם התאמה מושלמת.
הצפנה מקצה לקצה באמצעות SSL נתמכת הן על ידי SOAP והן על ידי REST, ו-REST יכול להשתמש ב-HTTPS, הגרסה המאובטחת של פרוטוקול HTTP.
5. טיפול במטענים
נתונים המועברים דרך האינטרנט נקראים מטען. מטען שנחשב "כבד" זקוק למשאבים נוספים. בהשוואה ל-SOAP, המשתמשת ב-XML, REST משתמשת לעתים קרובות ב-JSON וב-HTTP כדי לסייע בהפחתת המטען.
ספריית לקוח מיוחדת עם קוד שנוצר חייבת לשמש בדרך כלל את הלקוח כדי לגשת לממשקי SOAP API בגלל חוזה התקשורת המחמיר ביותר שלהם.
כתוצאה מכך, SOAP מציע רמת הפשטה פחותה מ-REST והוא קשור יותר לשרת.
מתי להשתמש ב-REST?
- יצירת ממשקי API ציבוריים: ממשקי API של REST מועדפים לבניית שירותי אינטרנט ציבוריים מכיוון שהם נראים פשוטים יותר לשימוש ולאימוץ מאשר ממשקי SOAP. בנוסף, SOAP מציעה מספר אמצעי אבטחה מובנים שאין ל-REST, אם כי מאפיינים אלו אינם נדרשים כאשר עובדים עם נתונים ושירותים פתוחים.
- בניית אפליקציות לנייד: REST מושלם לבניית יישומים ניידים מכיוון שהוא קטן, יעיל, חסר מצב וניתן לאחסון במטמון.
- ניצול משאבי שרת ורוחב פס נדירים: כל הבקשות ל-REST API חייבות להיות חסרות מצב, מה שאומר שכל אינטראקציה נפרדת וכל בקשה ותגובה מכילות את כל הנתונים הדרושים להשלמת האינטראקציה הזו. השרת אינו שומר רשומות של בקשות קודמות מכיוון שהוא מתייחס לכל אחת כבקשה חדשה. כתוצאה מכך, השרת דורש הרבה פחות זיכרון ופועל מהר יותר מכיוון שבקשה אינה מחייבת פעולה נוספת או אחזור של נתונים היסטוריים.
מתי להשתמש בסבון?
- יצירת ממשקי API פרטיים, במיוחד עבור עסקים גדולים: SOAP מושלם ליישומים ארגוניים מכיוון שהוא מאפשר זרימת נתונים בסביבה מבוזרת, מבוזרת ומכיל מספר תכונות אבטחה מקוונות.
- שימוש בפרוטוקול תעבורה שאינו HTTP כשכבה הבסיסית: SOAP אינו תלוי ב-HTTP כשכבה הבסיסית. בהתאם ליישום שלך, תוכל להשתמש ב-SMTP (פרוטוקול העברת דואר פשוט), JMS (שירות הודעות Java) או פרוטוקול תחבורה אחר.
- עבודה עם פעולות ממלכתיות: בניגוד לבקשות לממשקי API של REST, בקשות לממשקי API של SOAP הן מצביות, כלומר השרת שומר מידע על הלקוח ומנצל אותו על פני שרשרת של בקשות או פעולות. אפילו אם זה משתמש יותר ברוחב פס ומשאבים של השרת, זה חיוני לביצוע פעולות שגרתיות או מקושרות, כמו העברות בנקאיות.
סיכום
ההשוואה בין ממשקי API של REST ל-SOAP מבהירה היטב ש-REST עדיף על SOAP. למרות זאת, ישנם מצבים שבהם נדרש SOAP API. במקרים מסוימים, שירותי אינטרנט נוצרים על ידי שילוב של ממשקי API של REST ו-SOAP.
לכן, מקרה השימוש יקבע איזה סגנון API יעבוד הכי טוב.
השאירו תגובה