הסבר על ארכיטקטורה REST
/api/books לרשימת ספרים או /api/tasks למטלות. הכתובת מאפשרת לקרוא את המידע, ואם יש הרשאה גם לשנות אותו.פרקי ההרצאה: הסבר על ארכיטקטורה REST
תמלול ההרצאה: הסבר על ארכיטקטורה REST
הטקסט המלא של הדקות הראשונות בהרצאה «הסבר על ארכיטקטורה REST» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אחרי שראינו מה זה Web Service וראינו שאחת הארכיטקטורות הכי פופולריות ב-Web Service זה RESTful Service, בואו נצלול ונראה מה זה בדיוק REST, ארכיטקטורת REST. אז קודם כל הראשי תיבות, REST זה פשוט ראשי תיבות של Representational State Transfer.
זה בעצם ארכיטקטורה שהיום היא מאוד פופולרית לצורך יצירת סוג של Web Service. מה שמיוחד ב-REST זה שהוא משתמש בפרוטוקול HTTP בשביל לשלוח ולקבל מידע. הוא מגדיר שישה אילוצים שאם אנחנו בונים איזשהו Web Service שמשתמש או מכיל את האילוצים האלה, אז ה-Web Service הזה נחשב REST. REST לא אומר לכם איך לממש את האילוצים האלה,
הוא רק מגדיר גיידליינס כלליים, דיזיין גיידליינס, כלומר קווים כלליים של האילוצים האלה, אתם תממשו אותם בכל שפה, אפשר לבנות את זה ב-C-Sharp, אפשר לבנות את זה ב-Java, אפשר לבנות את זה ב-Node.js, JavaScript וכדומה.
מי שהגה את כל הרעיון הזה נקרא רוי פלדינג, בשנת 2000 הוא הגה את זה, וכאמור כל Web Service שמממש את הקווים האלה של REST נחשב ה-Restful Service, או קוראים לזה RESTful API, או פשוט רסט API. אז מה הם השישה אילוצים שמגדירים את רסט?
אילוץ ראשון נקרא Uniform Interface. מה שזה אומר, ושהמטרה של רסט זה לחשוף מידע, להנגיש מידע. מידע יושב בדאטאבייסים או בטבלאות, לדוגמה בדאטאבייס SQLי כלשהו, או ב-Collections, בדאטאבייס מסוג MongoDB לדוגמה, והטבלה הזאת או הקולקשן הזה, קולקשן זה משהו שמקביל לטבלה בדאטאבייס אחר, נקראים ריסורסז.
זה בעצם השם שנכון להתעסק איתו עם המידע עצמו של רסט. וכל ריסורס כזה חייב להיחשף על ידי לוג'יקל url ספציפי, url לוגי ספציפי אחד ויחיד ומדויק.
בואו נראה כמה דוגמאות. אם יש לנו לדוגמת טבלה של ספרים ואנחנו רוצים לחשוף אותה לעולם בעזרת רסט, אז אנחנו צריכים לתאר לינק ספציפי שאם גולשים אליו מקבלים את הספרים האלה.
לדוגמה, http://read.com/api/books. הרבה פעמים מקובל שה-URLים האלה יהיו נגישים על ידי המילה API. לדוגמה, יש לנו אוסף של מטלות באיזשהו אתר אינטרנט שחושף משימות שאנחנו יכולים להגדיר לעצמנו.
אז url כזה שחושף את המשימות יכול להיות http://mytasks.com זה בעצם השם של ה-url שלנו /api/tasks. דרך ה-API הזה אנחנו יכולים, דרך סליחה ה-URL הזה אנחנו יכולים לקבל את המידע ואם יש לנו הרשאות אז אנחנו יכולים גם לשנות את המידע כמו לתקן אותו, להוסיף אליו, למחוק אותו וכדומה.
אילוץ שני נקרא Client Server Model. זה בעצם מדבר על זה שהבנייה של ה-Client וה-Server, ואני מזכיר לכם, ה-Server זה ה-Restful Service שאנחנו בונים.
Client זה מי שמשתמש ב-Restful Server שלנו, גולש ומקבל את המידע. הם חייבים להיות משהו שנקרא Loosely Coupled בעברית, ונקרא צימוד רפוי.
אבל יותר מקובל השם loosely coupled. מה זה אומר? זה אומר שהקליינט והסרבר חייבים להיבנות ולהתפתח מבלי שיהיה ביניהם תלות אחד בשני.
זאת אומרת, התלות ביניהם היא ממש ממש loosely, רפואיה כזאת. כל אחד מהם לא יודע כלום או יודע מעט מאוד על האחר.
זה אומר שהקליינט, כל מה שהוא צריך לדעת בשביל לבנות אותו זה רק את ה-URLים של איך לקבל מידע מהסרבר, זה הכל. הוא לא אמור לדעת מה אמר הדאטאבייס, איך המידע מיוצג בדאטאבייס, מה שפת התכנות שהסרבר בנוי בה, איך הסרבר מכיל לוגיקה מסוימת, הוא לא אמור לדעת את כל הדברים האלה.
הסרבר מצד שני לא אמור לדעת כלום על הלקוח. כל מה שהוא אמור לעשות זה אם לקוח גולש אליו, ואולי הוא צריך לבדוק אם יש לו הרשאה וכדומה, שנראה בהמשך איך עושים את זה, הוא פשוט נותן לו את הדאטה, זה הכל. הוא לא יודע באיזה שפה הלקוח בנוי, מי הלקוח, מה הארכיטקטורה,
האם הלקוח הוא מובייל או ובסייט או וב סרוויס אחר, לא יודע את כל הדברים האלה. אילוץ מספר שלוש נקרא סטייטלס.
סטייטלס מתאר את הדאטה שיושב בצד של השרת. הדאטה שיושב בצד של השרת, במקרה הזה, כן, הוא בעצם לא אמור לזכור מה היה הדאטה הקודם שהלקוח ביקש. האינטראקציה בין הלקוח לשרת אמור להיות סטייטלס בצד של השרת עצמו.
הסרבר לא אמור לשמור שום דבר על הקריאה האחרונה שהלקוח ביצע. הוא אמור להתייחס לכל קריאה של כל לקוח כאילו זאת קריאה חדשה לגמרי, הוא לא זוכר מה היו הקריאות הקודמות, הוא לא זוכר מה הלקוח הקודם ביקש, הוא לא אמור לשמור לו שום דבר בצד של השרת לגבי הקריאות
האלה. אין שום דבר שנקרא סשן. הסשן הזה בעצם אובייקט שניתן לבנות בצד של השרת, שמחזיק מידע על הגלישות האחרונות של אותו לקוח.
אם סשן קיים פר לקוח, שום סשן לא תקף ב-Restful Service. הוא לא אמור לזכור שום דבר לגבי ההיסטוריה של הלקוח, הוא לא אמור לשמור את הבקשות האחרונות, הלקוח ביקש מבחינת היסטוריה בשביל לדעת להנגיש לו אולי דברים יותר טובים.
כל הדברים האלה אולי קיימים בכל מיני מקומות אחרים, מבחינת רסט אין שום דבר שקשור לשמירה של המידע של גלישות קודמות של הלקוחות.
אילוץ מספר 4 נקרא קאשאבל. קאש עושה פרפורמנס טוב יותר, משפר פרפורמנס. כל מה שקאש אומר זה בעצם היכולת לשמור ריסורס בצד של האפליקציה בזיכרון לדוגמה אם יש לנו טבלה מסוימת של מוצרים בוא ניקח טבלה של מוצרים שאותה טבלה אני רוצה לחשוף לגבי כל הלקוחות והמון לקוחות גולשים ורוצים את טבלת המוצרים
אז גלישה לדאטאבייס כל פעם בשביל לטעון את טבלת המוצרים והחזרת הטבלה לכל הלקוחות אולי זה משהו שגוזל זמן רב אז אולי כדאי לקחת את כל הטבלה ולשים אותה בזיכרון ואז גלישות חוזרות פשוט מביאות את כל הטבלה ללקוחות.
שימו לב, זה לא פר לקוח כמו סשן, זה אותו מידע לגבי כל הלקוחות. אז רסט ארכיטקצ'ר אומרת, קאש זה דבר שהוא מקובל וחוקי לגמרי ומבורך לביצוע.
במצב כזה ה-URL שחושף נניח את הטבלה הזאת, אם הוא חושף אותה כטבלה שהיא קשאבול, צריך להודיע או לייצג אותה כטבלה שהיא קשאבול. אולי בדוקומנטציה, אולי ב-URL לציין את זה באופן כלשהו.
אילוץ מספר 5 נקרא Layered System. זה בעצם אומר שהארכיטקטורה צריכה לתמוך במצב שהיא נחשבת Layered. זה אומר שהיא יכולה להיות משולבת על פני מספר מכונות או שרתים נפרדים.
לדוגמה, יש לנו שרת A ששומר את ה-Database, ושרת b שבכלל מבצע אותנטיקציה לראות אם היוזר הוא חוקי או יש לו יוזרנר ופאסוורד נכונים ובשרת גימל בכלל יש לנו חישוב מסוים שאנחנו צריכים.
ויכול להיות שיוזר עושה ריקווסט והריקווסט עוברת בין כל השרתים האלה וכל שרת צריך לדעת איך לספק רק את מה שהוא יודע לספק. אז רסט יכולה להיבנות ככזאת שתומכת בארכיטקטורה הזאת.
אילוץ מספר 6 נקרא Code on Demand. זה נחשב אופציונלי מפני שזה כבר תלוי בלוגיקה של הלקוח עצמו. רסט מאפשרת להחזיר ללקוח קוד שנחשב Executable, כלומר קוד שניתן להרצה.
זאת בשביל לתמוך באיזשהו חלק של האפליקציה בצד של הלקוח. דוגמה יכולה להיות שהשרת לא מחזיר לנו בהכרח דאטה טהור, אלא מחזיר קוד JavaScript שמסוגל לרוץ בצד של הלקוח בשביל לבצע איזשהו חישוב מסוים.
דוגמה אחרת יכולה להיות שהשרת ברסט מחזיר לנו קטע HTML-י שמחזיק איזשהו פיסת UI שאנחנו רוצים להציג בצד של הלקוח. אז קוד-אוד-מימנד מדבר על הדברים האלה שרסט יכול להחזיר את הקודים האלה שירוצו בקליינט סייד.
מה הקשר בין רסט ו-HTTP? אמרנו ש-Rest בנוי על גבי פרוטוקול HTTP. מה זה אומר? המידע שנשלח ומתקבל מ-Restful Service נמצא בתוך המסמכים של ה-HTTP.
ה-HTTP request מחזיק את המידע שנשלח מהקליינט ל-Restful Service שאנחנו בונים. ה-HTTP response מחזיר את המידע שאנחנו רוצים להחזיר ללקוח מה-Rest שאנחנו בונים בחזרה למי שביצע את הגלישה אלינו.
אז בואו נבין רגע איפה בדיוק המידע יושב בתוך מסמכי ה-HTTP, Request ו-Response. בואו נעשה איזושהי תזכורת קודם כל על ה-HTTP Request פורמט, על הפורמט עצמו.
אמרנו שיש סדרה של אזורים במסמך ה-Request של ה-HTTP. יש לנו את ה-Method או לפעמים קוראים לזה Verb, שמחזיק את מה הייעוד של הרקווסט, גט, פוסט וכדומה.
יש לנו את האזור של לאיזה דף אנחנו גולשים, ושוב זה HTTP רקווסט, כאילו אנחנו גולשים לדף רגיל. יש לנו את הגרסה של ה-HTTP. יש לנו את ההדרים והמידע הנלווה לרקווסט.
יש לנו Empty Line, שורה ריקה, ואז יש לנו את ה-Body, שזה המידע המרכזי שאנחנו רוצים לשלוח מהלקוח לשרת. הפורמט של ה-HTTP. איפה פה משתלב ה-Rest Data, ה-Rest Request?
שוב, יש את ששת החלקים האלה, ויש לנו את ה-Verb, מה אנחנו רוצים לבצע. אם אנחנו רוצים to get data, אם אנחנו רוצים to post data, זה באזור של ה-Verb.
כאן, במקום הדף שאליו אנחנו רוצים לגלוש, יש את אותו Resource URL, אותו חלק ב-URL שאומר לאן בדיוק אנחנו רוצים לגלוש, לא כולל הכתובת הראשית של האתר.
אנחנו תכף נראה דוגמה יותר ספציפית. לדוגמה, api/food, api/books, api/tasks וכדומה. כאן יש לנו את הגרסה של ה-HTTP, מפני שאנחנו HTTP request.
כל ההדרים של ה-HTTP נמצאים באזור הזה. כאן שוב יש לנו את ה-empty line ויש לנו את ה-arrest request data, אם אנחנו רוצים לשלוח מידע מסוים ב-Rest, כאן אנחנו עושים את זה.
HTTP ריספונס פורמט היה בא לחלקים הבאים. פה הייתה גרסת ה-HTTP, HTTP סטטוס קוד זה מספר שמתאר מה בעצם קרה, הצלחנו, לא הצלחנו, אם לא הצלחנו אז מה בדיוק הסיבה שלא הצלחנו.
HTTP סטטוס טקסט זה מילה או מספר מילים שמתארות את הסטטוס קוד. יש לנו את ה-HTTP Response Headers, שזה בעצם מה המידע הנלווה שהשרת שולח ללקוח.
יש לנו שורה ריקה, ויש לנו את המידע המרכזי שאנחנו שולחים מהשרת ללקוח. לדוגמה, אם הלקוח היה גולש לדף, כאן היינו שמים את ה-HTML של הדף.
איך רסט משתמשת בפורמט הזה בשביל לשלוח מידע מהשרת ללקוח? אזור ראשון, HTTP Version, נשאר אותו דבר, מה הגרסה של ה-HTTP?
סטטוס קוד נשאר אותו הדבר, מה בעצם קרה בצד של השרת? האם הצלחנו לתת לך את הבקשה? האם הייתה איזושהי שגיאה? HTTP סטטוס טקסט, בול אותו הדבר, נשאר מילה או מספר מילים שמתארות את הסטטוס קוד.
כל ההדרים, המידע הנלווה שאנחנו רוצים לשלוח מהשרת ללקוח, סיים אותו הדבר, שורה ריקה, והדאטה שאנחנו שולחים מהשרת ללקוח ברסט, נמצא באזור הזה, היה פה ה-HTTP ריספונס בודי.
פה ה-REST ריספונס דאטה יושב. בואו נראה כמה דוגמאות לריקווסט ולריספונס בארכיטקטוריית רסט. אז בואו נניח שאנחנו רוצים to get request, אנחנו רוצים להביא מידע משרת רסט.
המידע שאנחנו רוצים להביא נמצא ב-URL שנקרא /api/books. אנחנו כנראה רוצים להביא מידע לגבי ספרים. יש לנו כאן את גרסת ה-HTTP, בואו נניח ה-HTTP היא גרסה 1.1, והנה ההדרים, המידע הנלווה שאנחנו צריכים לתאר לסרבר.
לדוגמה, איפה הסרבר נמצא? בואו נניח שהסרבר, הכתובת שלו זה http.read.com, איזשהו אתר שהמצאתי. והכתובת IP address של היוזר נמצאת, אנחנו רואים כאן,