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

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

• לקוחות (לקוחות)
• הזמנות (הזמנות לקוחות)
• פריטים (מוצרים)

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

בקשות

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

• שיטת HTTP
• כּוֹתֶרֶת
• URI
• גוף הבקשה

להלן נשקול כל רכיב בפירוט רב יותר.

URIs ומשאבים

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

• לקוחות (לקוחות)
• הזמנות (הזמנות לקוחות)
• פריטים (מוצרים)

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

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

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

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

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

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

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

שיטת HTTP

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

• GET - קבל מידע על משאב מסוים (דרך המזהה שלו) או על אוסף של משאבים
• POST — צור משאב חדש
• PUT - שנה משאב (דרך המזהה שלו)
• מחק - מחק משאב (דרך המזהה שלו)

כותרות

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

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

לדוגמה, לבקשה יכולה להיות כותרת כזו:

Accept:application/json

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

גוף הבקשה

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

{
  "name" : "Amigo",
  "email" : "amigo@jr.com",
  "phone" : "+1 (222) 333-4444"
}

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

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

תגובות

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

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

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

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

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

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

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

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

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