פיצוץ RESTful APIs: חפירה עמוקה לתוך נקודות סיום ומשאבים

מדריכים

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

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

שני מושגים מרכזיים שקריטיים להבנת פעולתם של RESTful APIs הם: Endpoints ו- Resources

  • RESOURCES: משאבים הם כל מידע שניתן לזהות, לשם ולשנות. הם המופעים המרכזיים שנחשפים דרך ה- API.

  • ENDPOINT: נקודת גישה או כתובת ה- URL הספציפית או URI שמייצגת משאב או אוסף של משאבים שבאמצעותם לקוחות יכולים לאינטראקט עם ה- API.

העקרונות העיקריים של ארכיטקטורת RESTful, ידועים גם בשם אילוצי REST, מגדירים ביחד את ארכיטקטורת RESTful ומנחים את עיצוב שירותי האינטרנט שמצייתים לאילוצים אלו. העקרונות כוללים:

  • חסרות מצב: כל בקשה מלקוח לשרת חייבת לכלול את כל המידע הנדרש להבנת ועיבוד הבקשה. החסרות מצב משפרות קידמה ומפשטות את המימוש של השרת.

  • ממשק אחיד: אילוצים משניים כמו זיהוי משאב על ידי URL, ייצוג משאב על ידי תיאור, הודעה עצמית תיאורית, ואינטראקציה של לקוחות עם יישומים באמצעות היפרמדיה בלבד, הידועה כ- HATEOAS (היפרמדיה כמנוע של מצב היישום) מאפשרים ממשק אחיד ועקבי.

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

  • מערכת בשכבות: ישנן מספר שכבות עם כל שכבה יש לה פונקציות ספציפיות הנמצאות בארכיטקטורת REST. כל שכבה מתקשרת עם השכבה הצמודה כדי לקדם מודולריות וקידמה.

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

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

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

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

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

  • הגדרת פעולה: הקצוות מפרטים את הפעולה שלקוחות יכולים לבצע על משאבים. שיטות HTTP כמו GET, POST, PUT, ו-DELETE משמשות להגדרת הפעולה.

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

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

קיימים סוגים שונים של נקודות סיום המסווגים בהתבסס על פונקציונליות שלהם וסוגי הפעולות שהן תומכות בהן. כמה מהסוגים השונים הם:

  • נקודות סיום לקריאה ולאחזור: משמשות לאחזור משאבים מהשרת באמצעות שיטת ה- HTTP GET.

  • נקודות סיום ליצירה או POST: משמשות ליצירת משאבים חדשים בשרת באמצעות שיטת ה- HTTP POST

  • מחק נקודות קצה: משמש למחיקת משאב בשרת באמצעות שיטת DELETE של HTTP

  • עדכן או POST נקודות קצה: משמש לעדכון משאבים קיימים בשרת באמצעות שיטת PUT של HTTP.

  • חפש או שאילתה נקודות קצה: מאפשר ללקוחות לקבל תת קבוצה של משאבים בהתאם לקריטריונים מסוימים באמצעות שיטת GET של HTTP.

  • רשימת נקודות קצה: מחזירה אוסף או רשימת משאבים באמצעות שיטת GET של HTTP.

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

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

  • שימוש בשמות של עצמים עבור שמות המשאבים: במקום להשתמש בפועלים כמו "get" או "retrieve" בשם המשאב, יש להשתמש בשמות עצמים כמו "users" או "products".

  • כללי שמות משאבים: יש לעקוב אחר כללי שמות עקביים עבור המשאבים. יש להשתמש בשמות שקל להבין ולזכור.

  • שימו שמות רבים עבור אוספי משאבים: לדוגמה '/users' הוא אוסף של משאבי משתמש ו'/products' הוא אוסף של משאבי מוצר.

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

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

  • נקודות קצה כנקודות גישה: נקודת קצה היא ה- URI או URL הספציפי שמתאים למשאב או לאוסף של משאבים. היא מספקת נקודת גישה מוחשית דרך בה קליינטים יכולים לפעול עם המשאב.

  • נקודת קצה מזהה משאב: נקודת הקצה מזהה משאב או אוסף של משאבים. לדוגמה, אם יש לך משאב המייצג משתמשים, נקודת הקצה עשויה להיות '/users'.

  • שיטות HTTP מגדירות פעולות: נקודות הקצה משוייכות לשיטות HTTP ספציפיות (GET, POST, PUT, DELETE, וכו'), שמגדירות את הפעולות שניתן לבצע על המשאב התואם.

  • ייצוג המשאב: נקודת הקצה מבצעת תחלופות של המשאב עם השרת כאשר הלקוח מתקשר איתו. ייצוגים אלה עשויים להיות בפורמטים שונים כמו JSON או XML ולהכיל את המצב או המידע על המשאב. הייצוג הוא גוף בקשת או תשובת ה-HTTP.

  • ממשק אחיד: היחס בין משאבים ונקודות קצה עומד באילוצי הממשק האחיד של REST. השילוב בין משאבים ונקודות קצה יוצר מבנה API עקבי וניחודי.

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

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

Source:
https://inioluwa2003.hashnode.dev/demystifying-restful-apis-a-deep-dive-into-endpoints-and-resources