סקירה כללית של REST. חלק 2: תקשורת בין לקוח לשרת

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

• לקוחות - לקוחות;
• הזמנות - הזמנות לקוחות;
• פריטים - סחורה.

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

בקשות

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

• שיטת HTTP;
• כותרת;
• URI;
• גוף הבקשה.

להלן נסתכל על כל חלק מרכיב ביתר פירוט.

URI ומשאבים

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

• לקוחות - לקוחות;
• הזמנות - הזמנות לקוחות;
• פריטים - סחורה.

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

• /clients - URI של כל הלקוחות הקיימים;
• /clients/23 - URI של לקוח ספציפי, כלומר הלקוח עם ID=23;
• /clients/4 - URI של לקוח ספציפי, כלומר הלקוח עם ID=4.

אבל זה לא הכל. אנו יכולים להרחיב את ה-URI על ידי הוספת הזמנות אליו:

• /clients/4/orders — URI של כל ההזמנות של לקוח מס' 4;
• /clients/1/orders/12 - URI של הזמנה מס' 12 של לקוח מס' 1.

אם נמשיך בשרשרת זו ונוסיף סחורה, נקבל:

• /clients/1/orders/12/items — URI של רשימת כל המוצרים בהזמנה מס' 12 שנעשתה על ידי לקוח מס' 1.

עם רמות קינון, המפתח הוא להפוך את URIs אינטואיטיבי.

שיטת HTTP

שיטת HTTP (שיטת HTTP באנגלית) היא רצף של כל תווים, למעט פקדים ומפרידים, המציינים את הפעולה העיקרית במשאב. ישנן מספר שיטות HTTP נפוצות. אנו מפרטים את אלו המשמשים לרוב בשירותי RESTful:

• GET - משמש להשגת מידע על משאב ספציפי (באמצעות מזהה) או אוסף של משאבים;
• POST - משמש ליצירת משאב חדש;
• PUT - משמש לשינוי משאב (באמצעות מזהה);
• DELETE - משמש למחיקת משאב (באמצעות מזהה).

כותרות

בקשות, כמו גם תגובות, מכילות כותרות HTTP. הם שולחים מידע נוסף על הבקשה (או התגובה). כותרות הן צמדי מפתח-ערך. אתה יכול לקרוא את רשימת הכותרות הנפוצות ביותר בדף ויקיפדיה . עם REST, לקוחות יכולים לעתים קרובות לשלוח כותרת Accept בבקשתם לשרת. יש צורך ליידע את השרת באיזה פורמט הלקוח מצפה לקבל ממנו תגובה. אפשרויות פורמט שונות מוצגות ברשימת סוגי MIME. MIME (Multipurpose Internet Mail Extensions) הוא מפרט לקידוד מידע ועיצוב הודעות כך שניתן יהיה לשלוח אותן דרך האינטרנט. כל סוג MIME מורכב משני חלקים, מופרדים באמצעות קו נטוי: סוג ותת-סוג. דוגמאות לסוגי MIME עבור סוגי קבצים שונים:

• טקסט - טקסט/רגיל, טקסט/css, טקסט/html;
• תמונה - תמונה/png, תמונה/jpeg, תמונה/gif;
• אודיו - אודיו/wav, אודיו/mpeg;
• וידאו - וידאו/mp4, וידאו/ogg;
• application - application/json, application/pdf, application/xml, application/octet-stream.

בסך הכל, הבקשה עשויה לכלול את הכותרת הבאה:

Accept:application/json

כותרת זו אומרת לשרת שהלקוח מצפה לקבל תגובה בפורמט JSON.

גוף הבקשה

הודעה שנשלחה על ידי הלקוח לשרת. אם לבקשה יש גוף או לא תלוי בסוג בקשת ה-HTTP. לדוגמה, בקשות GET ו-DELETE בדרך כלל אינן מכילות גוף בקשה. אבל PUT ו-POST יכולים להכיל: זה הכל על המטרה הפונקציונלית של סוג הבקשה. אחרי הכל, כדי לקבל נתונים ולמחוק אותם לפי id (שמועבר ב-URL), אין צורך לשלוח נתונים נוספים לשרת. אבל כדי ליצור משאב חדש (בקשת POST), אתה צריך להעביר את המשאב הזה. אותו דבר לגבי שינוי משאב קיים. ב-REST, פורמטים של XML או JSON משמשים לרוב להעברת גוף הבקשה. הפורמט הנפוץ ביותר הוא JSON. נניח שאנו רוצים לשלוח בקשה לשרת, ובו ליצור משאב חדש. אם אתה זוכר, כדוגמה הסתכלנו על אפליקציה שמנהלת הזמנות של לקוחות. נניח שאנחנו רוצים ליצור לקוח חדש. במקרה שלנו, אנו מאחסנים את המידע הבא על לקוחות: שם דוא"ל מספר טלפון אז הגוף של בקשה כזו יכול להיות ה-JSON הבא:

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+7 (191) 746-43-23"
}

חיבור בקשות ביחד

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

תשובות

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

• קוד תגובה;
• כותרות;
• גוף תגובה.

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

קודי תגובה של HTTP

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

• 201 נוצר;
• 401 לא מורשה;
• 507 אחסון לא מספיק.

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

• 1ХХ - מידע;
• 2ХХ - ליידע על מקרים של קבלה ועיבוד מוצלחים של בקשת הלקוח;
• 3XX - להודיע ​​ללקוח כי על מנת לסיים את הפעולה בהצלחה, יש צורך להגיש בקשה נוספת, בדרך כלל באמצעות URI אחר;
• 4ХХ - שגיאת לקוח. לדוגמה, בקשה שנבנתה בצורה שגויה או הקוד הידוע 404 Not Found, שיכול להתרחש כאשר לקוח מבקש משאב לא קיים;
• 5ХХ - שגיאת שרת. הוחזר ללקוח אם הפעולה נכשלה עקב תקלת השרת.

תוכל לקרוא עוד על כל הקודים כאן . חלק 1: מה זה REST חלק 3: יצירת שירות RESTful ב-Spring Boot