REST vs WebSockets
1. Prehľad
V tomto výučbe sa oboznámime so základmi komunikácie medzi klientom a serverom a preskúmame ho prostredníctvom dvoch dnes populárnych možností. Uvidíme, ako WebSocket, ktorý je novým účastníkom, vedie proti populárnejšej voľbe RESTful HTTP.
2. Základy sieťovej komunikácie
Predtým, ako sa ponoríme do podrobností o rôznych možnostiach a ich výhodách a nevýhodách, rýchlo obnovme prostredie sieťovej komunikácie. Pomôže to uviesť veci na pravú mieru a lepšie to pochopiť.
Sieťovú komunikáciu možno najlepšie pochopiť v zmysle modelu otvoreného prepojenia systémov (OSI).
Model OSI rozdeľuje komunikačný systém na sedem vrstiev abstrakcie:
V hornej časti tohto modelu je aplikačná vrstva, o ktorú sa v tomto návode zaujímame. Budeme však diskutovať o niektorých aspektoch v prvých štyroch vrstvách, keď budeme porovnávať WebSocket a RESTful HTTP.
Aplikačná vrstva je najbližšia ku koncovému používateľovi a je zodpovedná za prepojenie s aplikáciami, ktoré sa zúčastňujú na komunikácii. V tejto vrstve sa používa niekoľko populárnych protokolov, ako sú FTP, SMTP, SNMP, HTTP a WebSocket.
3. Popis WebSocket a RESTful HTTP
Aj keď môže dochádzať ku komunikácii medzi ľubovoľným počtom systémov, zaujíma nás predovšetkým komunikácia typu klient-server. Konkrétnejšie sa zameriame na komunikáciu medzi webovým prehliadačom a webovým serverom. Toto je rámec, ktorý použijeme na porovnanie WebSocket s RESTful HTTP.
Ale skôr ako budeme pokračovať, prečo rýchlo nepochopiť, o čo ide!
3.1. Webové zásuvky
Ako vyplýva z formálnej definície, WebSocket je komunikačný protokol, ktorý umožňuje obojsmernú, plne duplexnú komunikáciu cez trvalé pripojenie TCP. Teraz budeme podrobne rozumieť každej časti tohto vyhlásenia.
WebSocket bol štandardizovaný ako komunikačný protokol IETF ako RFC 6455 v roku 2011. Väčšina moderných webových prehľadávačov dnes podporuje protokol WebSocket.
3.2. RESTful HTTP
Všetci sme si vedomí protokolu HTTP kvôli jeho všadeprítomnej prítomnosti na internete, ale zároveň ide o komunikačný protokol aplikačnej vrstvy. HTTP je protokol založený na požiadavke na odpoveď, opäť to lepšie pochopíme neskôr v tutoriále.
REST (Reprezentatívny prenos stavu) je architektonický štýl, ktorý kladie na HTTP obmedzenia vytvárať webové služby.
4. WebSocket Subprotocol
Zatiaľ čo WebSocket definuje protokol pre obojsmernú komunikáciu medzi klientom a serverom, nekladie to nijakú podmienku na správu, ktorá sa má vymieňať. To ponecháva stranám v komunikácii možnosť dohodnúť sa v rámci subprotokolového rokovania.
Nie je vhodné vyvíjať subprotokol pre netriviálne aplikácie. Našťastie existuje veľa populárnych subprotokolov ako STOMP. STOMP je skratka pre Simple Text Oriented Messaging Protocol a funguje cez WebSocket. Spring Boot má prvotriednu podporu pre STOMP, ktorú využijeme v našom návode.
5. Rýchle nastavenie v Spring Boot
Nie je nič lepšie ako vidieť fungujúci príklad. Zostavíme teda jednoduché prípady použitia v serveroch WebSocket aj RESTful HTTP, aby sme ich ďalej preskúmali a potom porovnali. Vytvorme pre oba jednoduchý serverový a klientský komponent.
Vytvoríme jednoduchého klienta pomocou JavaScriptu, ktorý pošle meno. A pomocou servera Java vytvoríme server, ktorý odpovie pozdravom.
5.1. WebSocket
Ak chcete používať WebSocket v Spring Boot, budeme potrebovať vhodný štartér:
org.springframework.boot spring-boot-starter-websocket Teraz nakonfigurujeme koncové body STOMP:
@Configuration @EnableWebSocketMessageBroker verejná trieda WebSocketMessageBrokerConfig implementuje WebSocketMessageBrokerConfigurer {@Override public void registerStompEndpoints (register StompEndpointRegistry) {registry.addEndpoint ("/ ws"); } @Override public void configureMessageBroker (konfigurácia MessageBrokerRegistry) {config.setApplicationDestinationPrefixes ("/ app"); config.enableSimpleBroker ("/ téma"); }}Poďme rýchlo definovať jednoduchý server WebSocket, ktorý prijme meno a odpovie pozdravom:
@Controller verejná trieda WebSocketController {@MessageMapping ("/ hello") @SendTo ("/ topic / greetings") verejné Pozdrav pozdravu (správa správy) vyvolá výnimku {return new Greeting ("Hello," + HtmlUtils.htmlEscape (message.getName) ()) + "!"); }}Nakoniec vytvorme klienta na komunikáciu s týmto serverom WebSocket. Pretože kladieme dôraz na komunikáciu medzi servermi, vytvorme klienta v JavaScripte:
var stompClient = null; function connect () {stompClient = Stomp.client ('ws: // localhost: 8080 / ws'); stompClient.connect ({}, function (frame) {stompClient.subscribe ('/ topic / greetings', function (response) {showGreeting (JSON.parse (response.body) .content);})}}); } funkcia sendName () {stompClient.send ("/ app / hello", {}, JSON.stringify ({'name': $ ("# name"). val ()})); } funkcia showGreeting (správa) {$ ("# pozdravy"). append ("„+ správa +“ Týmto je dokončený náš pracovný príklad servera a klienta WebSocket. V úložisku kódov je stránka HTML, ktorá poskytuje jednoduché používateľské rozhranie na interakciu.
Aj keď to iba poškriabe povrch, WebSocket s Spring sa dá použiť na vytvorenie komplexných klientov chatu a ďalších.
5.2. RESTful HTTP
Teraz prejdeme podobným nastavením služby RESTful. Naša jednoduchá webová služba prijme požiadavku GET s menom a odpovie pozdravom.
Namiesto toho tentokrát použijeme webový štartér Spring Boot:
org.springframework.boot spring-boot-starter-web Teraz definujeme koncový bod REST využívajúci výkonnú podporu anotácií, ktorá je k dispozícii na jar:
@RestController @RequestMapping (path = "/ rest") verejná trieda RestAPIController {@GetMapping (path = "/ {name}", produce = "application / json") public String getGreeting (@PathVariable ("name") názov reťazca) {return "{\" pozdrav \ ": \" Dobrý deň, "+ meno +"! \ "}"; }}Nakoniec vytvoríme klienta v JavaScripte:
var request = nová funkcia XMLHttpRequest () sendName () {request.open ('GET', '// localhost: 8080 / rest /' + $ ("# name"). val (), true) request.onload = funkcia () {var data = JSON.parse (this.response) showGreeting (data.greeting)} request.send ()} funkcia showGreeting (správa) {$ ("# pozdravy"). append ("„+ správa +“ To je skoro všetko! V úložisku kódov je opäť stránka HTML, ktorá pracuje s používateľským rozhraním.
Aj keď je jeho jednoduchosť hlboká, definovanie produkčného stupňa REST API môže byť oveľa rozsiahlejšou úlohou!
6. Porovnanie WebSocket a RESTful HTTP
Po vytvorení minimálnych, ale funkčných príkladov WebSocket a RESTful HTTP sme teraz pripravení pochopiť, ako sa im darí. Preskúmame to podľa niekoľkých kritérií v ďalších pododdieloch.
Je dôležité poznamenať, že aj keď môžeme priamo porovnávať protokoly HTTP a WebSocket, pretože sú to oba protokoly aplikačnej vrstvy, nie je prirodzené porovnávať REST s WebSocket. Ako sme videli skôr, REST je architektonický štýl, ktorý využíva na komunikáciu protokol HTTP.
Preto naše porovnanie s WebSocketom sa bude väčšinou týkať schopností alebo ich nedostatku v protokole HTTP.
6.1. Schéma URL
URL definuje jedinečné umiestnenie webového zdroja a mechanizmus na jeho načítanie. V komunikácii klient-server sa častejšie snažíme získať statické alebo dynamické prostriedky prostredníctvom ich pridruženej adresy URL.
Všetci poznáme schému HTTP URL:
// localhost: 8080 / zvyšokSchéma URL WebSocket sa tiež príliš nelíši:
ws: // localhost: 8080 / wsNa začiatku sa zdá, že jediným rozdielom sú znaky pred dvojbodkou, ale dosť sa to abstrahuje, čo sa deje pod kapotou. Poďme preskúmať ďalej.
6.2. Podanie ruky
Podanie rukyoznačuje automatický spôsob rokovania o komunikačnom protokole medzi komunikujúcimi stranami. HTTP je protokol bez štátnej príslušnosti a funguje v mechanizme odpovede na žiadosť. Pri každej požiadavke HTTP je nadviazané TCP spojenie so serverom cez soket.
Klient potom počká, kým server odpovie prostriedkom alebo chybou. Nasledujúca požiadavka od klienta opakuje všetko, akoby sa predchádzajúca požiadavka nikdy nestala:
WebSocket funguje v porovnaní s HTTP veľmi odlišne a pred skutočnou komunikáciou začína podaním ruky.
Pozrime sa, čo zahŕňa handshake WebSocket:
V prípade WebSocket, klient inicializuje požiadavku Protocol Handshake v HTTP a potom počká, kým server odpovie a prijme upgrade na WebSocket z HTTP.
Pretože sa protokol Handshake deje cez HTTP, postupuje samozrejme podľa postupnosti z predchádzajúceho diagramu. Ale akonáhle je spojenie nadviazané, odtiaľ sa klient a server prepnú na WebSocket pre ďalšiu komunikáciu.
6.3. Pripojenie
Ako sme videli v predchádzajúcej podkapitole, jedným výrazným rozdielom medzi WebSocket a HTTP je to, že WebSocket pracuje na trvalom pripojení TCP, zatiaľ čo HTTP vytvára nové pripojenie TCP pre každú požiadavku.
Vytváranie nového spojenia TCP pre každú požiadavku teraz zjavne nie je veľmi efektívne a protokol HTTP o tom nevedel. V skutočnosti boli ako súčasť protokolu HTTP / 1.1 zavedené trvalé spojenia, aby sa tento nedostatok protokolu HTTP zmiernil.
Napriek tomu WebSocket bol od základu navrhnutý pre prácu s trvalými TCP spojeniami.
6.4. Komunikácia
Výhodou protokolu WebSocket oproti protokolu HTTP je špecifický scenár, ktorý vyplýva zo skutočnosti, že klient môže serverom komunikovať spôsobmi, ktoré pri starom starom protokole HTTP neboli možné.
Napríklad v HTTP zvyčajne klient pošle túto požiadavku a potom server odpovie požadovanými údajmi. Pre server neexistuje žiadny všeobecný spôsob, ako komunikovať s klientom sám. Samozrejme, boli vyvinuté vzory a riešenia, ktoré to obchádzajú, ako napríklad udalosti odoslané serverom (SSE), ale neboli to úplne prirodzené.
S WebSocketom, pracujúcim na pretrvávajúcej komunikácii TCP, je možné, aby server aj klient odosielali údaje nezávisle na sebe, a v skutočnosti mnohým komunikujúcim stranám! Toto sa označuje ako obojsmerná komunikácia.
Ďalšia zaujímavá vlastnosť Komunikácia WebSocket spočíva v tom, že je plne duplexná. Zatiaľ čo tento výraz môže znieť ezotericky; to jednoducho znamená server aj klient môžu odosielať údaje súčasne. Porovnajte to s tým, čo sa deje v protokole HTTP, kde server musí čakať, kým prijme žiadosť v plnom rozsahu, aby mohol odpovedať údajmi.
Zatiaľ čo výhoda obojsmernej a plne duplexnej komunikácie nemusí byť zrejmá okamžite. uvidíme niektoré prípady použitia, keď odomknú skutočnú moc.
6.5. Bezpečnosť
V neposlednom rade, HTTP aj WebSocket využívajú na zabezpečenie výhody protokolu TLS. Zatiaľ čo HTTP ponúka https ako súčasť svojej schémy URL na použitie tohto kódu používa WebSocket wss ako súčasť ich schémy adries URL s rovnakým účinkom.
Zabezpečená verzia adries URL z predchádzajúcej podsekcie by mala vyzerať takto:
// localhost: 443 / rest wss: // localhost: 443 / wsZabezpečenie služby RESTful alebo komunikácie WebSocket je predmetom veľkej hĺbky a nemožno ho tu zahrnúť. Zatiaľ povedzme, že v tomto ohľade sú obaja primerane podporovaní.
6.6. Výkon
Musíme pochopiť, že WebSocket je stavový protokol, v ktorom sa komunikácia uskutočňuje prostredníctvom vyhradeného pripojenia TCP. Na druhej strane, HTTP je vo svojej podstate bezstavový protokol. To má vplyv na to, ako budú fungovať so záťažou, ale to skutočne závisí od prípadu použitia.
Pretože komunikácia cez WebSocket prebieha cez opakovane použiteľné pripojenie TCP, réžia na správu je v porovnaní s HTTP nižšia. Preto môže dosiahnuť vyššiu priepustnosť na server. Existuje ale limit, do ktorého je možné škálovať jeden server, a práve tam má WebSocket problémy. Nie je ľahké horizontálne škálovať aplikácie pomocou serverov WebSockets.
Tu svieti HTTP. Pomocou protokolu HTTP môže každá nová požiadavka potenciálne pristáť na ľubovoľnom serveri. To znamená, že na zvýšenie celkovej priepustnosti môžeme ľahko pridať viac serverov. To by potenciálne nemalo mať žiadny vplyv na aplikáciu spustenú pomocou protokolu HTTP.
Je zrejmé, že aplikácia môže sama potrebovať lepivosť stavu a relácie, čo uľahčuje jej vyslovovanie a vykonávanie.
7. Kde by sme ich mali používať?
Teraz sme videli dostatok služieb RESTful cez HTTP a jednoduchú komunikáciu cez WebSocket, aby sme si okolo nich vytvorili názor. Kde by sme však mali čo použiť?
Je dôležité mať na pamäti, že hoci sa WebSocket objavil na základe nedostatkov v protokole HTTP, v skutočnosti nejde o náhradu protokolu HTTP. Takže obaja majú svoje miesto a svoje využitie. Poďme rýchlo pochopiť, ako sa môžeme rozhodnúť.
Pre väčšinu scenára tam, kde sa vyžaduje občasná komunikácia so serverom, ako napríklad získanie záznamu zamestnanca, je stále rozumné používať službu REST cez HTTP / S. Ale pre novšie aplikácie na strane klienta, ako je aplikácia s akciovými cenami, ktorá vyžaduje aktualizácie zo servera v reálnom čase, je oveľa pohodlnejšie využívať WebSocket.
Zovšeobecnenie, WebSocket je vhodnejší pre prípady, keď tlačená komunikácia a komunikácia v reálnom čase definuje požiadavku vhodnejšie. Navyše, WebSocket funguje dobre pre scenáre, keď je potrebné poslať správu viacerým klientom súčasne. V týchto prípadoch bude komunikácia medzi klientom a serverom prostredníctvom služieb RESTful zložitá, ak nie neúnosná.
Napriek tomu je potrebné z požiadaviek čerpať použitie služieb WebSocket a RESTful cez HTTP. Pretože neexistujú žiadne strieborné guľky, nemôžeme len čakať, že si vyberieme jednu na vyriešenie každého problému. Preto musíme pri navrhovaní efektívneho modelu komunikácie využívať svoju múdrosť spojenú so znalosťami.
8. Záver
V tomto tutoriáli sme sa oboznámili so základmi sieťovej komunikácie s dôrazom na protokoly aplikačnej vrstvy HTTP a WebSocket. V Spring Boot sme videli niekoľko rýchlych ukážok WebSocket a RESTful API cez HTTP.
A nakoniec sme porovnali vlastnosti protokolov HTTP a WebSocket a stručne prediskutovali, kedy je treba ich použiť.
Ako vždy, kód príkladov je k dispozícii na GitHub.
