REST vs WebSockets
1. Oversigt
I denne vejledning gennemgår vi det grundlæggende i klient-server-kommunikation og udforsker dette gennem to populære muligheder, der er tilgængelige i dag. Vi får se, hvordan WebSocket, som er en ny aktør, klarer sig imod det mere populære valg af RESTful HTTP.
2. Grundlæggende i netværkskommunikation
Før vi dyber ned i detaljerne i forskellige muligheder og deres fordele og ulemper, lad os hurtigt opdatere landskabet for netværkskommunikation. Dette vil hjælpe med at sætte tingene i perspektiv og forstå dette bedre.
Netværkskommunikation kan bedst forstås i form af Open Systems Interconnection (OSI) -modellen.
OSI-modellen opdeler kommunikationssystemet i syv abstraktionslag:
Øverst i denne model er applikationslaget, som er af vores interesse i denne vejledning. Vi diskuterer dog nogle aspekter i de øverste fire lag, når vi sammenligner WebSocket og RESTful HTTP.
Applikationslaget er tættest på slutbrugeren og er ansvarlig for grænsefladen med de applikationer, der deltager i kommunikationen. Der er flere populære protokoller, der bruges i dette lag som FTP, SMTP, SNMP, HTTP og WebSocket.
3. Beskriver WebSocket og RESTful HTTP
Mens kommunikation kan ske mellem et hvilket som helst antal systemer, er vi især interesserede i klient-server kommunikation. Mere specifikt fokuserer vi på kommunikation mellem en webbrowser og en webserver. Dette er den ramme, vi bruger til at sammenligne WebSocket med RESTful HTTP.
Men inden vi går videre, hvorfor ikke hurtigt forstå, hvad de er!
3.1. WebSockets
Som den formelle definition går, WebSocket er en kommunikationsprotokol, der har tovejskommunikation, full-duplex-kommunikation over en vedvarende TCP-forbindelse. Nu vil vi forstå hver del af denne erklæring detaljeret, når vi går videre.
WebSocket blev standardiseret som en kommunikationsprotokol af IETF som RFC 6455 i 2011. De fleste moderne webbrowsere understøtter i dag WebSocket-protokollen.
3.2. HJÆLPENDE HTTP
Mens vi alle er opmærksomme på HTTP på grund af dets allestedsnærværende tilstedeværelse på internettet, er det også en applikationslagskommunikationsprotokol. HTTP er en anmodningsresponsbaseret protokoligen vil vi forstå dette bedre senere i vejledningen.
REST (Representational State Transfer) er en arkitektonisk stil, der sætter et sæt begrænsninger for HTTP at oprette webtjenester.
4. WebSocket subprotokol
Mens WebSocket definerer en protokol til tovejskommunikation mellem klient og server, det sætter ingen betingelser for den meddelelse, der skal udveksles. Dette er åbent for parterne i kommunikationen til at blive enige om som en del af subprotocol-forhandling.
Det er ikke praktisk at udvikle en subprotokol til ikke-trivielle applikationer. Heldigvis, der er mange populære subprotocols som STOMP tilgængelige til brug. STOMP står for Simple Text Oriented Messaging Protocol og fungerer via WebSocket. Spring Boot har førsteklasses support til STOMP, som vi bruger i vores tutorial.
5. Hurtig opsætning i Spring Boot
Der er ikke noget bedre end at se et fungerende eksempel. Så vi bygger enkle brugssager i både WebSocket og RESTful HTTP for at udforske dem yderligere og derefter sammenligne dem. Lad os oprette en simpel server og klientkomponent til begge.
Vi opretter en simpel klient ved hjælp af JavaScript, der sender et navn. Og vi opretter en server ved hjælp af Java, som svarer med en hilsen.
5.1. WebSocket
For at bruge WebSocket i Spring Boot skal vi bruge den rigtige starter:
org.springframework.boot spring-boot-starter-websocket Vi konfigurerer nu STOMP-slutpunkterne:
@Configuration @EnableWebSocketMessageBroker offentlig klasse WebSocketMessageBrokerConfig implementerer WebSocketMessageBrokerConfigurer {@ Override public void registerStompEndpoints (StompEndpointRegistry registry) {registry.addEndpoint ("/ ws"); } @ Override public void configureMessageBroker (MessageBrokerRegistry config) {config.setApplicationDestinationPrefixes ("/ app"); config.enableSimpleBroker ("/ topic"); }}Lad os hurtigt definere en simpel WebSocket-server, der accepterer et navn og svarer med en hilsen:
@Controller offentlig klasse WebSocketController {@MessageMapping ("/ hej") @SendTo ("/ topic / hilsner") offentlig hilsenhilsen (beskedbesked) kaster undtagelse {returner ny hilsen ("Hello" + HtmlUtils.htmlEscape (message.getName ()) + "!"); }}Lad os endelig bygge klienten til at kommunikere med denne WebSocket-server. Da vi lægger vægt på browser-til-server-kommunikation, lad os oprette en klient i JavaScript:
var stompClient = null; funktionsforbindelse () {stompClient = Stomp.client ('ws: // localhost: 8080 / ws'); stompClient.connect ({}, funktion (frame) {stompClient.subscribe ('/ topic / greetings', function (response) {showGreeting (JSON.parse (response.body) .content);});}); } funktion sendName () {stompClient.send ("/ app / hej", {}, JSON.stringify ({'navn': $ ("# navn"). val ()})); } funktion showGreeting (besked) {$ ("# hilsener"). tilføj (""+ besked +" Dette fuldender vores arbejdseksempel på en WebSocket-server og klient. Der er en HTML-side i kodelageret, der giver en enkel brugergrænseflade at interagere med.
Mens dette bare skraber overfladen, kan WebSocket med Spring bruges til at opbygge komplekse chatklienter og mere.
5.2. HJÆLPENDE HTTP
Vi gennemgår en lignende opsætning til RESTful service nu. Vores enkle webservice accepterer en GET-anmodning med et navn og svarer med en hilsen.
Lad os bruge Spring Boot's webstarter i stedet for denne gang:
org.springframework.boot spring-boot-starter-web Nu definerer vi et REST-slutpunkt, der udnytter kraftig annoteringsstøtte, der er tilgængelig i foråret:
@RestController @RequestMapping (sti = "/ resten") offentlig klasse RestAPIController {@GetMapping (sti = "/ {navn}", producerer = "applikation / json") offentlig String getGreeting (@PathVariable ("navn") Navn på streng) {return "{\" hilsen \ ": \" Hej, "+ navn +"! \ "}"; }}Lad os endelig oprette en klient i JavaScript:
var anmodning = ny XMLHttpRequest () funktion sendName () {request.open ('GET', '// localhost: 8080 / rest /' + $ ("# name"). val (), true) request.onload = funktion () {var data = JSON.parse (dette.svar) showGreeting (data.greeting)} anmodning.send ()} funktion showGreeting (besked) {$ ("# hilsen"). tilføj (""+ besked +" Det er stort set det! Igen er der en HTML-side i kodelageret, der fungerer med en brugergrænseflade.
Selvom det er dybtgående i sin enkelhed, kan det være meget mere omfattende at definere REST API for produktionskvalitet!
6. Sammenligning af WebSocket og RESTful HTTP
Efter at have skabt minimale, men fungerende eksempler på WebSocket og RESTful HTTP, er vi nu klar til at forstå, hvordan de klarer sig mod hinanden. Vi undersøger dette i forhold til flere kriterier i de næste underafsnit.
Det er vigtigt at bemærke, at mens vi direkte kan sammenligne HTTP og WebSocket, da de begge er applikationslagsprotokoller, det er ikke naturligt at sammenligne REST med WebSocket. Som vi så tidligere, er REST en arkitektonisk stil, der udnytter HTTP til kommunikation.
Derfor vores sammenligning med WebSocket vil for det meste være med hensyn til mulighederne eller manglen derpå i HTTP.
6.1. URL-ordning
En URL definerer den unikke placering af en webressource og mekanisme til at hente den. I en klient-server kommunikation søger vi oftere end ikke at få statiske eller dynamiske ressourcer gennem deres tilknyttede URL.
Vi er alle fortrolige med HTTP URL-ordningen:
// localhost: 8080 / restWebSocket URL-skema er heller ikke meget anderledes:
ws: // localhost: 8080 / wsI begyndelsen ser det ud til, at den eneste forskel er tegnene før tyktarmen, men det abstrakterer meget, der sker under emhætten. Lad os udforske videre.
6.2. Håndtryk
Håndtrykhenviser til den automatiske måde at forhandle kommunikationsprotokol mellem kommunikerende parter på. HTTP er en statsløs protokol og fungerer i en anmodningssvarmekanisme. På hver HTTP-anmodning oprettes en TCP-forbindelse med serveren over stikket.
Klienten venter derefter, indtil serveren reagerer med ressourcen eller en fejl. Den næste anmodning fra klienten gentager alt, som om den tidligere anmodning aldrig skete:
WebSocket fungerer meget forskelligt i forhold til HTTP og starter med et håndtryk inden egentlig kommunikation.
Lad os se, hvad der består af et WebSocket-håndtryk:
I tilfælde af WebSocket klienten initierer en Protocol Handshake-anmodning i HTTP og venter derefter, indtil serveren reagerer og accepterer en opgradering til WebSocket fra HTTP.
Da protokolhåndtryk sker via HTTP, følger det selvfølgelig rækkefølgen fra det foregående diagram. Men når forbindelsen er oprettet, skifter klient og server derfra til WebSocket for yderligere kommunikation.
6.3. Forbindelse
Som vi så i det foregående underafsnit, er en skarp forskel mellem WebSocket og HTTP, at WebSocket fungerer på en vedvarende TCP-forbindelse, mens HTTP opretter en ny TCP-forbindelse til hver anmodning.
Nu er det klart, at oprettelse af ny TCP-forbindelse til hver anmodning ikke er særlig effektiv, og HTTP har ikke været uvidende om dette. Faktisk blev der som en del af HTTP / 1.1 indført vedvarende forbindelser for at afhjælpe denne mangel ved HTTP.
Alligevel, WebSocket er designet fra bunden til at arbejde med vedvarende TCP-forbindelser.
6.4. Meddelelse
Fordelen ved WebSocket over HTTP er et specifikt scenarie, der skyldes, at klienten kan servere kan kommunikere på måder, der ikke var mulige med god gammel HTTP.
For eksempel i HTTP sender klienten normalt den anmodning, og derefter svarer serveren med anmodede data. Der er ingen generisk måde for serveren at kommunikere med klienten alene. Selvfølgelig er der udtænkt mønstre og løsninger til at omgå dette som Server-Sent Events (SSE), men disse var ikke helt naturlige.
Med WebSocket arbejder du på vedvarende TCP-kommunikation, det er muligt for server og klient begge at sende data uafhængigt af hinanden, og faktisk til mange kommunikerende parter! Dette kaldes tovejskommunikation.
Et andet interessant træk ved WebSocket-kommunikation er, at det er fuld duplex. Nu mens dette udtryk måske lyder esoterisk; det betyder simpelthen det både server og klient kan sende data samtidigt. Sammenlign dette med hvad der sker i HTTP, hvor serveren skal vente, indtil den modtager anmodningen fuldt ud, før den kan svare med data.
Mens fordelen ved tovejskommunikation og fuld duplekskommunikation muligvis ikke er tydelig med det samme. vi ser nogle af brugstilfældene, hvor de låser op for ægte magt.
6.5. Sikkerhed
Sidst men ikke mindst, både HTTP og WebSocket udnytter fordelene ved TLS til sikkerhed. Mens HTTP tilbyder https som en del af deres URL-skema for at bruge dette, har WebSocket wss som en del af deres URL-skema for den samme effekt.
Så den sikrede version af webadresser fra det foregående underafsnit skal se ud:
// localhost: 443 / rest wss: // localhost: 443 / wsSikring af enten en RESTful service eller en WebSocket-kommunikation er meget dybtgående og kan ikke dækkes her. Lad os lige nu sige, at begge understøttes tilstrækkeligt i denne henseende.
6.6. Ydeevne
Vi må forstå, at WebSocket er en stateful protokol, hvor kommunikation sker via en dedikeret TCP-forbindelse. På den anden side er HTTP i sagens natur en statsløs protokol. Dette har indflydelse på, hvordan disse fungerer med belastningen, men det afhænger virkelig af brugssagen.
Da kommunikation via WebSocket sker over en genanvendelig TCP-forbindelse, er omkostningerne pr. Besked lavere sammenlignet med HTTP. Derfor kan det nå højere gennemstrømning pr. Server. Men der er en grænse, som en enkelt server kan skaleres til, og det er her WebSocket har problemer. Det er ikke let at skalere applikationer vandret med WebSockets.
Det er her, HTTP skinner. Med HTTP kan hver ny anmodning muligvis lande på enhver server. Dette indebærer, at vi let kan tilføje flere servere for at øge den samlede kapacitet. Dette bør potentielt ikke have nogen indvirkning på applikationen, der kører med HTTP.
Det er klart, at en applikation muligvis i sig selv har brug for tilstands- og sessionsklibhed, hvilket kan gøre det lettere sagt end gjort.
7. Hvor skal vi bruge dem?
Nu har vi set nok af RESTful service over HTTP og enkel kommunikation via WebSocket til at danne vores mening omkring dem. Men hvor skal vi bruge hvad?
Det er vigtigt at huske, at mens WebSocket er kommet ud af mangler i HTTP, er det faktisk ikke en erstatning for HTTP. Så de har begge deres plads og deres anvendelser. Lad os hurtigt forstå, hvordan vi kan træffe en beslutning.
For størstedelen af scenariet hvor lejlighedsvis kommunikation er påkrævet med serveren som at få en medarbejderregister, er det stadig fornuftigt at bruge REST-tjenesten via HTTP / S. Men for nyere applikationer på klientsiden som en aktiekursapplikation, der kræver opdateringer i realtid fra serveren, er det meget praktisk at udnytte WebSocket.
Generalisering, WebSocket er mere velegnet til tilfælde, hvor en push-baseret og realtidskommunikation definerer kravet mere passende. Derudover WebSocket fungerer godt i scenarier, hvor en meddelelse skal skubbes til flere klienter samtidigt. Dette er de tilfælde, hvor klient- og serverkommunikation via RESTful-tjenester vil finde det vanskeligt, hvis ikke uoverkommeligt.
Ikke desto mindre skal brugen af WebSocket- og RESTful-tjenester over HTTP trækkes ud fra kravene. Som om der ikke er nogen sølvkugler, kan vi ikke bare forvente at vælge en til at løse ethvert problem. Derfor skal vi bruge vores visdom kombineret med viden til at designe en effektiv kommunikationsmodel.
8. Konklusion
I denne vejledning gennemgik vi det grundlæggende i netværkskommunikation med vægt på applikationslagsprotokoller HTTP og WebSocket. Vi så nogle hurtige demonstrationer af WebSocket og RESTful API over HTTP i Spring Boot.
Og endelig sammenlignede vi funktionerne i HTTP- og WebSocket-protokoller og diskuterede kort, hvornår de skulle bruges.
Som altid er koden til eksemplerne tilgængelig på GitHub.
