REST לעומת WebSockets

1. סקירה כללית

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

2. יסודות תקשורת רשת

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

ניתן להבין בצורה הטובה ביותר את תקשורת הרשת במונחים של מודל ה- OSI (Interconnection).

מודל OSI מחלק את מערכת התקשורת לשבע שכבות של הפשטה:

בראש מודל זה נמצאת שכבת היישום שמעניינת אותנו במדריך זה. עם זאת, נדון בכמה היבטים בארבע השכבות המובילות תוך כדי השוואה בין WebSocket ו- HTTP RESTful.

שכבת היישום היא הקרובה ביותר למשתמש הקצה ואחראית על התממשקות ליישומים המשתתפים בתקשורת. ישנם מספר פרוטוקולים פופולריים המשמשים בשכבה זו כמו FTP, SMTP, SNMP, HTTP ו- WebSocket.

3. תיאור WebSocket ו- HTTP RESTful

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

אבל לפני שנמשיך הלאה, מדוע לא להבין במהירות מה הם!

3.1. WebSockets

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

WebSocket הותקן כפרוטוקול תקשורת על ידי IETF כ- RFC 6455 בשנת 2011. רוב דפדפני האינטרנט המודרניים כיום תומכים בפרוטוקול WebSocket.

3.2. HTTP נחמד

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

REST (העברת מדינות ייצוגית) הוא סגנון אדריכלי שמציב סט אילוצים על HTTP כדי ליצור שירותי אינטרנט.

4. סאב-פרוטוקול WebSocket

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

זה לא נוח לפתח פרוטוקול משנה ליישומים לא טריוויאליים. לְמַרְבֶּה הַמַזָל, ישנם הרבה סוגי סאב-פרוטוקולים פופולריים כמו STOMP זמינים לשימוש. STOMP מייצג פרוטוקול העברת הודעות פשוט טקסט ועובד דרך WebSocket. ל- Spring Boot יש תמיכה מהשורה הראשונה ב- STOMP, בה נשתמש במדריך שלנו.

5. התקנה מהירה באביב אתחול

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

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

5.1. WebSocket

כדי להשתמש ב- WebSocket ב- Boot Boot, נצטרך המתנע המתאים:

 org.springframework.boot spring-boot-starter-websocket 

כעת נגדיר את נקודות הקצה של STOMP:

@Configuration @EnableWebSocketMessageBroker בכיתה ציבורית WebSocketMessageBrokerConfig מיישם את WebSocketMessageBrokerConfigurer {@ Override public void registerStompEndpoints (StompEndpointRegistry registry) {registry.addEndpoint ("/ ws"); } @Override public void configureMessageBroker (תצורת MessageBrokerRegistry) {config.setApplicationDestinationPrefixes ("/ app"); config.enableSimpleBroker ("/ נושא"); }}

בואו נגדיר במהירות שרת WebSocket פשוט שמקבל שם ומגיב בברכה:

@Controller מחלקה ציבורית WebSocketController {@MessageMapping ("/ שלום") @SendTo ("/ נושא / ברכות") ברכת ברכה ציבורית (הודעת הודעה) זורקת חריג {להחזיר ברכה חדשה ("שלום" + HtmlUtils.htmlEscape (message.getName ()) + "!"); }}

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

var stompClient = null; function connect () {stompClient = Stomp.client ('ws: // localhost: 8080 / ws'); stompClient.connect ({}, פונקציה (מסגרת) {stompClient.subscribe ('/ נושא / ברכות', פונקציה (תגובה) {showGreeting (JSON.parse (response.body). תוכן);});}); } פונקציה sendName () {stompClient.send ("/ app / hello", {}, JSON.stringify ({'name': $ ("# name"). val ()})); } פונקציה showGreeting (הודעה) {$ ("# ברכות"). להוסיף (""+ הודעה +""); }

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

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

5.2. HTTP נחמד

נעבור כעת מערך דומה לשירות RESTful. שירות האינטרנט הפשוט שלנו יקבל בקשת GET עם שם ומגיב בברכה.

בואו נשתמש במקום זאת בפתיח האינטרנט של Spring Boot:

 org.springframework.boot spring-boot-starter-web 

כעת נגדיר נקודת קצה של REST המנצלת תמיכה ביאורים רבת עוצמה הזמינה באביב:

@RestController @RequestMapping (path = "/ rest") מחלקה ציבורית RestAPIController {@GetMapping (path = "/ {name}", מייצר = "יישום / json") ציבורי מחרוזת getGreeting (@PathVariable ("שם") שם מחרוזת) {return "{\" ברכה \ ": \" שלום, "+ שם +"! \ "}"; }}

לבסוף, בואו ניצור לקוח ב- JavaScript:

var בקשה = פונקציה XMLHttpRequest () חדשה sendName () {request.open ('GET', '// localhost: 8080 / rest /' + $ ("# name"). val (), true) request.onload = function () {var data = JSON.parse (this.response) showGreeting (data.greeting)} request.send ()} פונקציה showGreeting (הודעה) {$ ("# ברכות"). להוסיף (""+ הודעה +""); }

זה פחות או יותר זה! שוב, יש במאגר הקוד עמוד HTML שיעבוד עם ממשק משתמש.

אף על פי שהיא עמוקה בפשטותה, הגדרת REST API של כיתת ייצור יכולה להיות משימה נרחבת בהרבה!

6. השוואה בין WebSocket ו- HTTP RESTful

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

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

לָכֵן ההשוואה שלנו ל- WebSocket תהיה בעיקר לגבי היכולות או היעדרן ב- HTTP.

6.1. תוכנית URL

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

כולנו מכירים את תוכנית ה- URL של HTTP:

// localhost: 8080 / מנוחה

גם תוכנית ה- URL של WebSocket אינה שונה בהרבה:

ws: // localhost: 8080 / ws

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

6.2. לחיצת ידיים

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

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

WebSocket עובד בצורה שונה מאוד בהשוואה ל- HTTP ומתחיל בלחיצת יד לפני תקשורת בפועל.

בואו נראה מה כולל לחיצת יד של WebSocket:

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

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

6.3. חיבור

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

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

על כל פנים, WebSocket תוכנן מהיסוד לעבודה עם חיבורי TCP מתמשכים.

6.4. תִקשׁוֹרֶת

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

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

עם WebSocket, עובד על תקשורת TCP מתמשכת, זה אפשרי עבור השרת והלקוח שניהם לשלוח נתונים בלתי תלויים זה בזה, ולמעשה, למסיבות תקשורת רבות! זה מכונה תקשורת דו-כיוונית.

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

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

6.5. בִּטָחוֹן

אחרון חביב, הן HTTP והן WebSocket ממנפים את היתרונות של TLS לאבטחה. בעוד HTTP מציע https כחלק מתכנית ה- URL שלהם להשתמש בזה, יש ל- WebSocket wss כחלק מתוכנית ה- URL שלהם לאותו אפקט.

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

// localhost: 443 / rest wss: // localhost: 443 / ws

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

6.6. ביצועים

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

מכיוון שתקשורת דרך WebSocket מתרחשת באמצעות חיבור TCP רב פעמי, התקורה להודעה נמוכה יותר בהשוואה ל- HTTP. מכאן שהוא יכול להגיע לתפוקה גבוהה יותר לשרת. אבל יש גבול שאליו שרת יחיד יכול להתמקד, וכאן יש ל- WebSocket בעיות. לא קל לשנות גודל אופקי של יישומים באמצעות WebSockets.

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

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

7. היכן עלינו להשתמש בהם?

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

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

עבור חלק הארי של התרחיש כאשר נדרשת תקשורת מדי פעם עם השרת כמו השגת רשומה של עובד, עדיין הגיוני להשתמש בשירות REST באמצעות HTTP / S. אך עבור יישומים חדשים יותר בצד הלקוח כמו יישום מחיר מניות הדורש עדכונים בזמן אמת מהשרת, זה הרבה יותר נוח למנף את WebSocket.

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

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

8. מסקנה

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

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

כמו תמיד, הקוד לדוגמאות זמין ב- GitHub.


$config[zx-auto] not found$config[zx-overlay] not found