סקירה כללית של 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. HTTP ראשי תיבות של HyperText Transfer Protocol. בדרך כלל, שרת הוא יישום אינטרנט כלשהו. הלקוח יכול להיות כמעט כל דבר. לדוגמה, אפליקציה לנייד שמבקשת נתונים משרת. או דפדפן ששולח בקשות מדף אינטרנט לשרת על מנת להוריד נתונים. יישום A עשוי לבקש נתונים מיישום B. במקרה זה, A הוא לקוח ביחס ל-B, ו-B הוא שרת ביחס ל-A. במקביל, A יכול לעבד בקשות מ-B, C, D וכו'. במקרה זה, יישום A הוא גם שרת וגם לקוח. הכל תלוי בהקשר. דבר אחד בטוח: הרכיב ששולח את הבקשה הוא הלקוח. הרכיב שמקבל, מעבד ומגיב לבקשה הוא השרת. עם זאת, לא כל מערכת שמרכיביה מתקשרים באמצעות תהליך של תגובה לבקשה היא מערכת RESTful. כדי שמערכת תיחשב RESTful, עליה לעמוד בששת אילוצי REST:

1. ארכיטקטורת שרת-לקוח

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

2. חסר אזרחות

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

3. ניתן לקובץ שמור

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

4. ממשק אחיד

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

5. שכבות

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

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

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

היתרונות של ארכיטקטורה RESTful

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

• ביצועים (עקב שימוש במטמון)
• מדרגיות
• תקשורת שקופה
• ממשקים פשוטים
• הִטַלטְלוּת
• היכולת לבצע שינויים בקלות
• יכולת להתפתח ולהסתגל לדרישות חדשות

סקירה כללית של REST. חלק 2: תקשורת בין לקוח לשרת סקירה כללית של REST. חלק 3: בניית שירות RESTful על Spring Boot