הערת העורך: המאמר הבא נכתב ופורסם בדווזון לשנת 2024 בדווח המגמות,ניהול API מודרני: חיבור מבנים מונחה על נתונים ביחד עם AI, אוטומציה ומיקרוסרבים.
APIs משחקות תפקיד מרכזי בעולם הפיתוח התוכנה המודרני. סוגים רבים של APIs יכולים לשמש להקמת תקשורת וחילוף נתונים בין מערכות שונות. בחזית נמצא הגישה של REST, ששלטה בתעשייה בזכות הפשטות והסקלריות שלה. עם זאת, ככל שהטכנולוגיה התפתחה, הדרישות של מפתחים ועסקים השתנו גם כן. בשנים האחרונות, חליפין כגון GraphQL ו-APIs מונחה על אירועים אסימפטומיים גם הם הופיעו. הם מציעים יתרונות מובהקים על פני APIs רסט מסורתיים.
במאמר זה, נבחן כל אחת מטכנולוגיות ה-API הללו ונבנה הבנה השוואתית שלהן.
REST: ההתחלה של תקשורת מונחה על משאבים
ארכיטקטורת REST מסתמכת על הרעיון של משאבים. אלה הם ישויות שניתן לנהל באמצעות שיטות HTTP רגילות כגון GET, POST, PUT ו-DELETE. אחת המאפיינים המרכזיים של REST היא טבעה החסר מצב, שבו כל בקשה מלקוח מכילה את כל המידע הדרוש לשרת למלא אותה. זה מנתק את הלקוח והשרת, מאפשר להם להתרחב בנפרד.
יתרונות וחסרות של REST
ל-APIs רסט יש כמה יתרונות משמעותיים:
- REST עוקב אחר עיצוב פשוט ואינטואיטיבי המבוסס על שיטות HTTP סטנדרטיות.
- כל בקשה בגישת REST היא בלתי תלויה, מה שמוביל להתקדמות טובה יותר בהישגיה ובאמינות.
- REST מנצל מנגנוני צימוד HTTP כדי לשפר את הביצועים ולהפחית את העומס על שרת המקור.
- REST היא פעלולי, עובדת היטב עם שפות תכנות ורשתות שונות בזכות הפורמט הסטנדרטי שלה.
עם זאת, ארכיטקטורת REST גם כוללת מספר חסרונות:
- אפיניות REST יכולה להוביל להמלצה יתר, כשלקוחות מקבלים יותר מידע ממה שצריך, מה שמוביל לאי יעילות ובזבוז של פסי תקשורת.
- כמו בנקודה הראשונה, אפיניות REST יכולה גם לסבול מהמלצה חסרה, כשצריך בקשות מרובות כדי לענות על דרישות מידע מורכבות. זה גורם לעיכובים מוגברים.
- REST עוקב אחר גישה סינכרונית שיכולה להוביל לחסימה ולבעיות ביצועים בתרחישים בהם יש עומס גבוה.
- שינויים במבנה הנתונים של ה-API יכולים להשפיע על הלקוחות, מה שמוביל לקשר הדדי הדוק.
מקרים שימוש ב-API של REST
יש מקרים שימוש אידאליים שבהם API של REST מתאימים הרבה יותר מאשר סוגים אחרים של API, למשל:
- יישומים עשירים בצימוד – יישום שמורכב בעיקר מקריאות, כמו אתרי חדשות או תוכן סטטי, יכול להשיג תועלת ממנגנון הצימוד של REST. ההנחיות הסטנדרטיות לצימוד ב-REST מקלות על היישום.
- פעולות CRUD פשוטות – כשמתמודדים עם פעולות CRUD פשוטות, רשתות REST מציעות פשטות וניתוח מתאים. יישומים עם מודל נתונים ברור וקבוע מרבים למצוא רשתות REST מתאימות יותר.
GraphQL: העליה של איתות נתונים מסר עם APIs
GraphQL היא שילוב של שפה פתוחה וחופשית לשאילתת נתונים וגם ריצה למילוי שאילתות אלה. העיקרון המרכזי מאחורי GraphQL הוא שימוש במבנה היררכי להגדרת שאילתות נתונים, מה שמאפשר ללקוחות לציין במדויק את הנתונים שהם צריכים בבקשה יחידה.
איור 1. GraphQL בתמונה הגדולה
במספר דרכים, GraphQL היה תגובה ישירה לבעיות עם ארכיטקטורת REST API המסורתית.
עם זאת, היא מקדמת סכמה ממונעת חזק, מה שמספק למפתחים רעיון ברור לגבי מה לצפות. GraphQL תומכת בעדכוני נתונים בזמן אמת דרך מנויים. לאורך השנים, קרתה הרבה עבודה על כלים כמו GraphQL Federation כדי להפוך את API GraphQL לנפחיים יותר עבור תאגידים גדולים עם מספר תחומים.
יתרונות וחסרונות של GraphQL
GraphQL מספקת כמה יתרונות מרכזיים:
- עם GraphQL, ללקוחות יכולים לבקש רק את הנתונים הספציפיים שהם צריכים. זה מבטל את בעיות העולם והתת-עולם עם רשתות REST.
- גישת הסכמה ממונעת חזק של GraphQL מספקת מבנה ברור ואימות, מה שמאיץ את הפיתוח והתיעוד.
- GraphQL פועל בדרך כלל דרך מספר יחיד של נקודת קצה. ללקוחות מספיק לדאוג רק לנקודת קצה יחידה בעת שיחה עם שרת GraphQL, למרות שעשויות להיות מקורות רבים לנתונים.
- מתוך הבנייה האינטרוספקציה מאפשרת ללקוחות לחקור את השייקמא ולגלות את הנתונים והפעולות הזמינים.
ישנם גם מספר חסרונות ל-GraphQL:
- יישום GraphQL דורש שיפורים נוספים במאמץ ובידע בהשוואה ל-REST APIs המסורתיים.
- מאחר והשאילתות ב-GraphQL הן גמישות, אגירת נתונים יכולה להיות מאתגרת ועשויה דרושה פתרונות מותאמים אישית.
- בעוד ש-GraphQL מפחית באופן משמעותי את ההישג של דברים נוספים ברמה העליונה, שאילתות מקופלות עדיין יכולות להוביל ל-איסוף נתונים מיותר.
- בעלות על שכבת GraphQL המשותפת הופכת למבוכה, שלא כמו אזורי הגבול הברורים של ה-REST API.
מקרים שימוש ב-GraphQL
ישנם תרחישים ספציפיים בהם GraphQL משחק תפקיד טוב יותר בהשוואה ל-REST APIs, למשל:
- דרישות נתונים מורכבות ומקופלות – כדי להשיג נתונים עם יחסים מורכבים, GraphQL עוזר ללקוחות לציין במדויק את הנתונים שהם זקוקים להם בשאילתה יחידה.
- עדכוני נתונים בזמן אמת – מנויי GraphQL עוזרים ליישומים להתמודד עם עדכוני נתונים בזמן אמת, כגון יישומי צ'אט או ניירות עמדה חיים. עם GraphQL, לקוחות יכולים להירשם לשינויים בנתונים מסוימים, מה שמאפשר עדכונים בזמן אמת מבלי שיהיה צורך בסריקה תדירה.
- ארכיטקטורות מיקרוסרביסים – במקרה זה, הנתונים מפוזרים ברחבי שירותים רבים. GraphQL מספק ממשק מאוחד עבור הלקוחות לבקש נתונים משירותים שונים. אפליקציית הלקוח אינה צריכה לנהל מספר רב של נקודות קצה REST.
API אסימכטיים: תנועה לארכיטקטורת דינמיקה מונחה
במהלך השנים, הדחיפה לאמץ או לעבור לארכיטקטורה מקורית לענן גם העלתה ארכיטקטורות דינמיות, והיתרון הוא הסיכוי לתקשורת לא מחוסרת זמן בין הרכיבים. עם API אסימכטיים, ללקוחות אין צורך להמתין לתגובה לפני שהם ממשיכים קדימה. הם יכולים לשלוח בקשות ולהמשיך את תהליכי הביצוע שלהם. גישה כזו היא יתרון עבור תרחישים שדורשים תוספת גבוהה של עיכוב, סקלביליות ומעורריות.
במערכות דינמיות, API אסימכטיים מטפלים באירועים ובהודעות יחד עם עזרה מטכנולוגיות כמו אפאכה קפקא ו-רביבימק, שמספקות תווך לתקשורת בין יצרן הודעה לצרכן.
בהתחשב במערכת טיפוסית שמשתמשת בגישת API דינמית, יש לנו יצרנים שמפרסמים אירועים לנושאים, וצרכנים שמרשים לנושאים אלה כדי לקבל ולעבד את האירועים אסימכטית. זה מאפשר סקלביליות וחסינות לכשל ללא שיכוך מכיוון שיצרנים וצרכנים יכולים להתפתח בנפרד. התרשים הבא מציג מערכת כזו:
המסך 2. מערכת דינמית עם קפקא ו-API אסימכטיים
יתרונות וחסרונות של APIs אסימכרוניים
ישנם כמה יתרונות מרכזיים של APIs אסימכרוניים:
- APIs אסימכרוניים מתאימים היטב להתמודדות עם עלייה בשידורים מקביליות ודרישות התרחבותיות מאחר שניתן לטפל במקביל במספר רב של בקשות.
- APIs אסימכרוניים גם מאפשרים עיבוד מידע בזמן אמת על ידי מתן תגובה מוקדמת לאירועים.
- APIs אסימכרוניים יכולים גם לעזור להשיגת שימוש מיטבי במשאבים של המערכת על ידי העברת משימות לתהליכים רקורדיים.
- לבסוף, APIs אסימכרוניים מגבירים את הרוחב הפגיע של המערכת כפי שכשרכיב אחד מת זה לא משתק את כל המערכת.
עם זאת, כמו סוגים אחרים של APIs, APIs אסימכרוניים גם כוללים מספר חסרונות:
- יש להגברת מורכבות סביב משלוח הודעות, סדר וניהול שגיאות.
- APIs אסימכרוניים הם יותר קשים לאבחון ובדיקה.
- מערכות שנבנו באמצעות APIs אסימכרוניים לעתים מסתיימות בעקביות סופית, כשעדכוני נתונים אינם משתתפים מייד בכל הרכיבים.
- APIs אסימכרוניים יכולים גם להעלות עלות ביחס למערכות מיוחדות לניהול הודעות.
תרומות של APIs אסימכרוניים
ישנם מספר תרומות אידאליות לAPIs אסימכרוניים כאשר משווים אותם ל-REST ו-GraphQL APIs, כולל:
- זרימת נתונים בזמן אמת – ממשקי API אסינכרוניים הם הבחירה הטובה ביותר לצרכים של זרימת נתונים בזמן אמת, כגון זרימות חברתיות, עדכונים של שוק ההון ונתונים מחיישני IoT. יישומים אלה מייצרים כמויות גדולות של נתונים שצריכים להיות מעובדים ומשודרים ללקוחות בזמן קרוב לאמת.
- שילוב עם מערכות שלישיות – ממשקי API אסינכרוניים מתאימים מאוד לשילוב עם מערכות שלישיות שעשויות להיות בעלות זמני תגובה לא צפויים או SLAs של זמינות.
- משימות רקע – לבסוף, יישומים הדרושים ביצוע משימות רקע – כגון שליחת מיילים, הודעות או עיבוד תמונות/וידאו – יכולים להשתמש באפיונים של ממשקי API אסינכרוניים.
השוואה צד-צד של REST, GraphQL ו-API אסינכרוניים
בחנו את כל שלושת סוגי מבני API. הגיע הזמן להשוות אותם צד-צד כדי שנוכל לקבל החלטות טובות יותר בנוגע לבחירה בין אחד מעל השני. הטבלה שלהלן מציגה את ההשוואה על פני מספר פרמטרים:
טבלה 1. השוואה בין REST, GraphQL ו-API אסינכרוניים
| Parameter | REST APIs | GraphQL APIs | Asynchronous APIs |
| Data fetching approach | Data is fetched with predefined endpoints | Clients specify the exact data requirements in the query | Data is passed in the form of asynchronous messages |
| Performance and scalability | Highly suitable for scalable applications; can suffer from overfetching and underfetching problems | Scalable; nested queries can be problematic | Highly scalable; efficient for real-time data processing |
| Flexibility and ease of use | Limited flexibility in querying data | High flexibility for querying data | Limited flexibility in querying data and requires understanding of an event-driven approach |
| Developer experience and learning curve | Well established and familiar to many developers | Moderate learning curve in terms of understanding the GraphQL syntax | Steeper learning curve |
| Real-time capabilities | Limited real-time capabilities, relying on techniques like polling and webhooks for updates | Real-time capabilities through subscriptions | Designed for real-time data processing; highly suitable for streaming applications |
| Tooling and ecosystem support | Abundant tooling and ecosystem support | Growing ecosystem | The need for specialized tools such as messaging platforms like RabbitMQ or Kafka |
סיום
במאמר זה, בחנו את ההבדלים המרכזיים בין מבנים API שונים: REST, GraphQL ו-API אסימכרוניים. בנוסף, הבחנו בתרחישים בהם סוג מסוים של API עשוי להיות מתאים יותר מאחרים. מבט לעתיד, נולדת הזדמנות לשינוי נוסף בנוף הפיתוח של API. טכנולוגיות על כנף כגון בינה מלאכותית, חישוב קצה ו-IoT יגרמו לדרישות חדשות המחייבות את התפתחות גישות API. כמו כן, עם הגידול המהיר של מערכות מיקומיות, ה-API ישמש בתפקיד מרכזי באפשרויות התקשורת.
כמפתח, חשוב מאוד להבין את היתרונות והמוגבלויות של כל סגנון API ולבחור בגישה המתאימה ביותר לדרישה נתונה. חשיבה זו יכולה לעזור למפתחים לנווט בנוף ה-API בבטחון.
זהו קטע מדווח DZone 2024, ניהול API מודרני: חיבור מבנים מונחה על נתונים ביחד עם AI, אוטומציה ומיקרוסרבים.
Source:
https://dzone.com/articles/understand-api-technologies-comparative-analysis