סקירה כללית של REST. חלק 1: מהי REST

שלום, היום נלמד נושא מאוד מעניין, והכי חשוב, מבוקש בשוק העבודה - REST. נחלק את הסקירה הכללית של REST לשלושה חלקים:

1. בחלק הראשון ניגע בהיסטוריה של REST ונתאר את העקרונות שעליהם מבוסס REST.

2. בשנייה, נבחן כיצד מתרחשת תקשורת בין הלקוח לשרת באמצעות פרוטוקול HTTP.

3. בשלישית נכתוב אפליקציית RESTful קטנה, אותה נבדוק באמצעות תוכנת Postman.

המאמר מיועד לקורא שמכיר את המונחים הבאים:

• HTTP;
• כתובת URL ו-URI;
• JSON ובמידה פחותה XML;
• הזרקת תלות.

חלק 1. מה זה REST

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

היסטוריה של REST

את המונח REST טבע רוי פילדינג, אחד מיוצרי פרוטוקול ה-HTTP, בעבודת הדוקטורט שלו "סגנונות אדריכליים ועיצוב ארכיטקטורות תוכנה מבוססות רשת" בשנת 2000. אנו יכולים לומר שהמונח REST עדיין צעיר, למרות שהמושג שלו נמצא בבסיס ה-World Wide Web. לא נצלול עמוק לתוך ההיסטוריה של מקור המונח הזה. אם אתה רוצה לצלול לתוך המקורות המקוריים, עיין בעבודת הדוקטורט של פילדינג .

מגבלות ועקרונות REST

כפי שצוין לעיל, REST מגדיר כיצד רכיבי מערכת מבוזרת צריכים לקיים אינטראקציה זה עם זה. באופן כללי, זה קורה באמצעות בקשה-תגובה. הרכיב ששולח את הבקשה נקרא הלקוח ; הרכיב שמעבד את הבקשה ושולח תגובה ללקוח נקרא שרת . בקשות ותגובות נשלחות לרוב באמצעות HTTP (פרוטוקול HyperText Transfer). בדרך כלל, שרת הוא סוג של יישום אינטרנט. הלקוח יכול להיות לא סתם כל דבר, אלא די הרבה. לדוגמה, אפליקציה סלולרית המבקשת נתונים מהשרת. או דפדפן ששולח בקשות מדף אינטרנט לשרת כדי להוריד נתונים. אפליקציה א' יכולה לבקש נתונים מאפליקציה ב'. ואז A הוא לקוח ביחס ל-B, ו-B הוא שרת ביחס ל-A. במקביל, א' יכול לעבד בקשות מ-C, D, D וכו'. במקרה זה, יישום A הוא גם שרת וגם לקוח. הכל תלוי בהקשר. דבר אחד ברור: הרכיב ששולח את הבקשה הוא הלקוח. הרכיב שמקבל, מעבד ומגיב לבקשה הוא השרת. עם זאת, לא כל מערכת שרכיביה מתקשרים באמצעות בקשה-תגובה היא מערכת REST (או RESTful). כדי שמערכת תיחשב RESTful, עליה "להתאים" לשישה אילוצי REST:

1. הבאת הארכיטקטורה למודל שרת-לקוח

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

2. חוסר מצב

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

3. שמירה במטמון

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

4. אחידות הממשק

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

5. שכבות

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

6. קוד לפי דרישה (הגבלה אופציונלית)

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

היתרונות של REST

לאפליקציות העומדות בכל ההגבלות לעיל יש את היתרונות הבאים: אמינות (אין צורך לאחסן מידע על מצב הלקוח, שעלול ללכת לאיבוד);

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

חלק 2: תקשורת בין לקוח לשרת חלק 3: יצירת שירות RESTful ב-Spring Boot