HTTP og Websockets: Forstå mulighederne i dagens webkommunikationsteknologier

Beslutter, hvad du skal vælge til dit næste web API-design

Der er så mange klassifikationer til API'er. Men når det kommer til webkommunikation, kan vi identificere to betydelige API-typer - Web Service API'er (f.eks. SOAP, JSON-RPC, XML-RPC, REST) ​​og Websocket API'er. Men hvad betyder disse egentlig? Lad os dykke ned i en verden af ​​webkommunikationsprotokoller og diskutere, hvordan vi vælger de bedste API-mekanismer til sidst.

HTTP

HTTP er den underliggende kommunikationsprotokol på World Wide Web. HTTP fungerer som en anmodning-svar-protokol i klient-server-computermodellen. HTTP / 1.1 er den mest almindelige version af HTTP, der bruges i moderne webbrowsere og servere. I sammenligning med tidlige versioner af HTTP kunne denne version implementere kritiske ydelsesoptimeringer og funktionsforbedringer såsom vedvarende og pipelined forbindelser, chunkede overførsler, nye headerfelter i anmodning / svarlegeme osv. Blandt disse er de følgende to overskrifter meget bemærkelsesværdige, fordi de fleste af de moderne forbedringer af HTTP er afhængige af disse to overskrifter.

  • Hold-Alive-overskrift for at indstille politikker for langvarig kommunikation mellem værter (timeoutperiode og maksimalt antal anmodninger om at håndtere pr. Forbindelse)
  • Opgrader overskrift for at skifte forbindelsen til en forbedret protokoltilstand såsom HTTP / 2.0 (h2, h2c) eller Websockets (websocket)

Hvis du er interesseret i at vide, hvad disse virkelig gør, har jeg dokumenteret alle vigtige oplysninger til dig i nedenstående artikel.

HVILE

Den arkitektoniske stil REST (REpresentational State Transfer) er langt den mest standardiserede måde at strukturere web-API'erne til anmodninger om. REST er rent en arkitektonisk stil baseret på flere principper. API'erne, der overholder REST-principperne, kaldes RESTful APIs. REST API'er bruger en anmodning / svar model, hvor hver meddelelse fra serveren er svaret på en meddelelse fra klienten. Generelt bruger RESTful API'er HTTP som sin transportprotokol. I sådanne tilfælde skal opslag bruge GET-anmodninger. PUT-, POST- og DELETE-anmodninger skal bruges til henholdsvis mutation, oprettelse og sletning (undgå at bruge GET-anmodninger om opdatering af oplysninger).

HTTP-polling

I HTTP-polling afstemmer klienten serveren, der anmoder om ny information ved at overholde en af ​​nedenstående mekanismer. Polling bruges af langt de fleste applikationer i dag, og de fleste af tiderne går til RESTful praksis. I praksis bruges HTTP kort polling meget sjældent, og HTTP lang polling eller periodisk polling er altid valget.

  • HTTP Short Polling: Enklere tilgang. En masse anmodninger behandles, når de kommer til serveren, hvilket skaber en masse trafik (bruger ressourcer, men frigør dem, så snart svaret sendes tilbage). Da hver forbindelse kun er åben i en kort periode, kan mange forbindelser være tidsmultiplexerede.
00:00:00 C-> Er kagen klar?
00:00:01 S-> Nej, vent.
00:00:01 C-> Er kagen klar?
00:00:02 S-> Nej, vent.
00:00:02 C-> Er kagen klar?
00:00:03 S-> Ja. Har nogle gutter.
00:00:03 C-> Er den anden kage klar?
  • HTTP lang polling: En anmodning går til server og klient venter på, at svaret kommer. Serveren holder anmodningen åben, indtil nye data er tilgængelige (de er uopløst, og ressourcerne er blokeret). Du får besked uden forsinkelse, når serverhændelsen finder sted. Mere komplekse og flere serverressourcer brugt.
HTTP lang polling - Der holdes respons, indtil serverprocesdata (billede fra shyamapadabatabyal.wordpress.com)
12:00 00:00:00 C-> Er kagen klar?
12:00 00:00:03 S-> Ja. Har nogle gutter.
12:00 00:00:03 C-> Er den anden kage klar?
  • Periodisk polling af HTTP: Der er en foruddefineret tidsafstand mellem to anmodninger. Dette er en forbedret / administreret version af polling. Du kan reducere serverforbruget ved at øge tidsforskellen mellem to anmodninger. Men hvis du skal have besked uden forsinkelse, når serverhændelsen finder sted, er dette ikke en god mulighed.
Periodisk polling af HTTP - Anmodning sendes hvert n sekund (Billede fra ibm.com)
00:00:00 C-> Er kagen klar?
00:00:01 S-> Nej, vent.
00:00:03 C-> Er kagen klar?
00:00:04 S-> Ja. Har nogle gutter.
00:00:06 C-> Er den anden kage klar?

HTTP-streaming

HTTP-streaming - giver en langvarig forbindelse til øjeblikkelig og kontinuerlig datapush (Billede fra realtimeapi.io)

Klient indstiller en HTTP-anmodning, og serveren udslipper et svar af ubestemt længde (det er som polling uendeligt). HTTP-streaming er performant, let at forbruge og kan være et alternativ til websockets.

  • Spørgsmål: Formidlere kan afbryde forbindelsen (f.eks. Timeout, formidlere, der betjener andre anmodninger på en rund-robin måde). I sådanne tilfælde kan det ikke garantere fuldstændig realitet.
00:00:00 KLIENT-> Jeg har brug for kager
00:00:01 SERVER-> Vent et øjeblik.
00:00:01 SERVER-> Cake-1 er i gang.
00:00:02 SERVER-> Har kage-1.
00:00:02 SERVER-> Vent på kage-2.
00:00:03 SERVER-> Cake-2 er i gang.
00:00:03 SERVER-> Du skal nyde kage-1.
00:00:04 SERVER-> Har kage-2.
00:00:04 SERVER-> Vent til kage-3.
00:00:05 KLIENT-> Nok, jeg er fuld.

SSE (Server sent events / EventSource)

SSE - begivenheder kan sendes til flere klienter (Billede fra javaee.ch)
  • SSE-forbindelser kan kun skubbe data til browseren. (kommunikation udføres kun fra server til browser, browsere kan kun abonnere på dataopdateringer, der stammer fra serveren, men kan ikke sende nogen data til serveren)
00:00:00 KLIENT-> Jeg har brug for kager
00:00:02 SERVER-> Har kage-1.
00:00:04 SERVER-> Har kage-2.
00:00:05 KLIENT-> Nok, jeg er fuld.
  • Eksempel på applikationer: Twitter-opdateringer, aktiekurser, cricket-scores, meddelelser til browseren
  • Problem nr. 1: Nogle browsere understøtter ikke SSE.
  • Udgave nr. 2: Maksimalt antal åbne forbindelser er begrænset til 6 eller 8 over HTTP / 1.1 (baseret på browserversion). Hvis du bruger HTTP / 2, er der ikke noget problem, fordi en enkelt TCP-forbindelse er nok til alle anmodninger (takket være multiplekset support i HTTP / 2).

HTTP / 2-server-push

  • En mekanisme for en server til proaktivt at skubbe aktiver (stilark, scripts, medier) til klientcachen på forhånd
  • Eksempel på applikationer: Feeds til sociale medier, apps på en side
HTTP / 2 er et effektivt transportlag baseret på multipleksede streams (Image from SessionStack.com) - I følge IETF er en “stream” en uafhængig, tovejs sekvens af rammer, der udveksles mellem klienten og serveren inden for en HTTP / 2-forbindelse. En af dens vigtigste egenskaber er, at en enkelt HTTP / 2-forbindelse kan indeholde flere samtidigt åbne streams, med begge endepunktsinterfolierammer fra flere strømme.
  • Problem nr. 1: Formidlere (proxies, routere, værter) kan vælge ikke at skubbe information til klienten korrekt, som den er beregnet af originalserveren.
  • Problem nr. 2: Forbindelser holdes ikke åbne på ubestemt tid. En forbindelse kan lukkes når som helst, også når indholdspresningsprocessen sker. Når den først er lukket og åbnet igen, kan denne forbindelse ikke fortsætte, hvor den gik tilbage.
  • Problem nr. 3: Nogle browsere / formidlere understøtter ikke Server Push.

WebSockets

WebSockets giver både serveren og klienten mulighed for at skubbe meddelelser til enhver tid uden nogen forbindelse til en tidligere anmodning. En bemærkelsesværdig fordel ved brug af websockets er næsten hver browser understøtter websockets.

WebSocket løser et par problemer med HTTP:

  • Tovejs-protokol - enten klient / server kan sende en meddelelse til den anden part (I HTTP startes anmodningen altid af klienten, og svaret behandles af serveren - hvilket gør HTTP til en envejs-protokol)
  • Full-duplex-kommunikation - klient og server kan tale med hinanden uafhængigt på samme tid.
  • Enkelt TCP-forbindelse - Efter opgradering af HTTP-forbindelsen i begyndelsen kommunikerer klient og server over den samme TCP-forbindelse gennem hele livscyklussen til Websocket-forbindelsen.
00:00:00 KLIENT-> Jeg har brug for kager
00:00:01 SERVER-> Vent et øjeblik.
00:00:01 KLIENT-> Okay, cool.
00:00:02 SERVER-> Har kage-1.
00:00:02 SERVER-> Vent på kage-2.
00:00:03 KLIENT-> Hvad er denne smag?
00:00:03 SERVER-> Kan du ikke lide det?
00:00:04 SERVER-> Har kage-2.
00:00:04 KLIENT-> Jeg kan godt lide det.
00:00:05 KLIENT-> Men dette er nok.
Websocket-forbindelse (billede fra PubNub.com)

Eksempel på applikationer: IM / chat-apps, spil, administratorfronter

Selvom det siges, at websockets understøttes i hver browser, kan der også være undtagelser i formidlere:

  • Uventet opførsel i formidlere: Hvis dine websocket-forbindelser gennemgår proxies / firewalls, har du måske bemærket, at sådanne forbindelser mislykkes hele tiden. Brug altid Secured Websockets (WSS) til drastisk at reducere sådanne fejl. Denne sag er pænt forklaret her: Hvordan HTML5 Web Sockets interagerer med Proxy-servere og også her: WebSockets, forsigtighed krævet !. Så vær forsigtig, og gør dig klar til at håndtere dem ved at bruge WSS og falde tilbage til en støttende protokol.
  • Formidlere, der ikke understøtter websockets: Hvis WebSocket-protokollen af ​​en eller anden grund ikke er tilgængelig, skal du sørge for, at din forbindelse automatisk falder tilbage til en passende lang pollingindstilling.

REST vs Websockets - Perf Test

Hvis du udfører en ydelsestest for REST og Websockets, kan du opleve, at Websockets klarer sig bedre, når der er store belastninger. Dette betyder ikke nødvendigvis, at REST er ineffektiv. Min personlige mening er, at sammenligne REST med Websockets er som at sammenligne æbler med appelsiner. Disse to funktioner løser to forskellige problemer og kan ikke sammenlignes med en simpel perf-test som denne:

I den første graf stiger REST-overhead mod antallet af meddelelser, fordi mange TCP-forbindelser skal initieres og afsluttes, og at mange HTTP-headere skal sendes og modtages. I den anden graf er de trinvise omkostninger til behandling af anmodning / svar til et REST-endepunkt minimale, og det meste af tiden bruges til forbindelse initiering / afslutning og hædring af HTTP semantik. (Perfektest og analyse fra arungupta.me)

Du skal dog nu forstå, at websockets er et godt valg til håndtering af langvarig tovejsstrømning på næsten realtid, mens REST er fantastisk til lejlighedsvis kommunikation. Brug af websockets er en betydelig investering, og det er derfor en overdreven brug for lejlighedsvise forbindelser.

Webhooks (til kommunikation mellem servere)

Hvis du vil hente data fra din API ved ændring af data, skal afstemning være den første mulighed, der kommer til dit sind. Men når det kommer til kommunikation mellem servere, koster ineffektivitet i polling os meget (gennemsnitligt bliver 98,5% af afstemningerne spildt).

Webhooks - enkel måde at sende data mellem servere uden langvarige pollingforbindelser (Billede fra realtimeapi.io)

Webhooks er frelseren for dette problem. Husk her, at kommunikationen generelt sker mellem servere. Først registrerer afsenderknuden en tilbagekalds-URL i modtagerens knudepunkter på forhånd. Når der sker en begivenhed på afsendersiden, udløses webhooken og sender et hændelsesobjekt med nye data som en HTTP POST-anmodning til modtagerens knudepunkt ved hjælp af tilbagekalds-URL'er, der er registreret i hver af dem.

Den seje ting er, at serverbelastning for både afsender- og modtagernoder kan reduceres drastisk med webhooks. Det sikrer den bedre brugeroplevelse, mens dine udviklere kan bruge dine serviceendepunkter til meningsfulde ting uden at spilde til polling.

Webhooks bruges normalt til at sende meddelelser og tilstede ændringer blandt servere, når en begivenhed opstår. For eksempel, når en bruger afmelder sig via et knappeklik i e-mail, den kommer til en server, og brugeren afmelder begivenheden, denne begivenhed udløser de tilsvarende webhooks og de giver besked om alle de servere / tjenester, som brugeren nu har afmeldt fra deres service (Billede fra kloudymail.com)
  • Eksempel på applikationer: Underretninger, når en ny bruger registrerer sig, eller en nuværende bruger opdaterer en eksisterende profilindstilling
  • Problem: Udviklere har svært ved at konfigurere webhooks og skalere HTTP-tjenester.

Hvad skal du bruge til din næste API?

Hvilken teknik der skal bruges afhænger af, hvad der giver større mening i forbindelse med din ansøgning. Sikker på, du kan bruge nogle tricks til at simulere adfærd for en teknologi med den anden, men det foretrækkes normalt at bruge det, der passer til din kommunikationsmodel bedre, når det bruges af bogen.

HTTP / 1.1 vs HTTP / 2: Dette er transportprotokoller. Mutiplexing-funktionen i HTTP / 2 er stor, men understøttes endnu ikke overalt. I sådanne tilfælde skal du sørge for at falde tilbage fra HTTP / 2 og HTTP / 1.1 ikke skaber noget rod i din applikation. For overførsel af data er HTTP / 1.1 stadig et godt valg.

RESTful APIs: Indtil videre er RESTful APIs okay til webapplikationer. Men der sker diskussioner om at udforske bedre måder. Et eksempel er dette koncept - "Erstat RESTful APIs med JSON-Pure". Jeg kan godt lide ideen, faktisk er JSON udviklervenlig, og du kan gøre vidundere med den. Men du ved, disse er ved at udvikle koncepter.

JSON vs XML: Brug JSON. Det er trenden og så praktisk at håndtere også.

HTTP-polling: Dette er gammelt, men stadig et godt valg til at håndtere API'er. Hvis dine data ændres hyppigt eller i realtid, skal du ikke bruge Short Polling, bare bruge websockets, den bedre teknologi til realtid. Brug altid lang og periodisk polling korrekt (med REST-principper).

HTTP-streaming: Dette er godt til applikationer som nyheder / sociale medie-feeds, lager / score boards, tweets osv. Men i praksis bruger folk websockets end HTTP-streaming.

HTTP / 2 Server Push er fantastisk til at sende ressourcer til klienten på mere administreret måde. Men alle formidlere og browsere understøtter ikke dette. Sørg for, at du yndefuldt håndterer sådanne tilbageslag.

Server-sendte begivenheder er en temmelig ny teknologi, som endnu ikke understøttes af alle større browsere, så det er endnu ikke en mulighed for en seriøs webapplikation på virksomhedsniveau (Ja, jeg er enig i, at du kan narre denne teknologi til at fungere).

WebSockets giver en rigere protokol til at udføre tovejs, fuld-dupleks kommunikation. At have en tovejskanal er mere attraktivt for ting som spil, messaging-apps, samarbejdsværktøjer, interaktive oplevelser (inkl. Mikro-interaktioner) og for tilfælde, hvor du har brug for realtidsopdateringer i begge retninger.

Webhooks er forskellige fra alle ovennævnte teknologier, fordi det løser et meget specifikt problem. Hvis dine servere har brug for at kommunikere ofte og / eller tovejs, skal du gå til websockets. Hvis dine servere lejlighedsvis kommunikerer, skal du bruge REST-opkald. Hvis dine servere har brug for at kommunikere ensrettet på en hændelsesudløser, skal du gå til webhooks. Brug ikke polling til at kontrollere ændringer i data eller tilstand, det er spild.

Nogle tip?

️ Fuldmagter og formidlere er skøre. De spiser uventet dine pakker eller timeout. Vær opmærksom på det og håndter det yndefuldt.

️ Brug sikrede transportprotokoller (HTTPS eller WSS) til at håndtere din kommunikation. Derefter vil formidlere have mindre indflydelse på dine forbindelser. Og det er sikkert, ved du.

️ Udviklere elsker webhooks. Men sørg for at anvende det rigtigt.

️ Du behøver virkelig ikke at omfavne den nyeste teknologi altid, især når du opretter applikationer på virksomhedsniveau. Sørg for, at al infrastrukturen understøtter den teknologi, du bruger. Og hvis infrastrukturen ikke understøtter din teknologi / arkitektur, skal du sørge for, at den falder tilbage til en teknologi, der bare fungerer overalt, og at alt fungerer yndefuldt med nedsatte kapaciteter.

Referencer:

  • REST vs WebSocket Sammenligning og benchmark
  • Kort polling vs lang polling til realtids webapplikationer?
  • Kom godt i gang med realtid