HTTP en websockets: inzicht in de mogelijkheden van de hedendaagse webcommunicatietechnologieën

Beslissen wat u kiest voor uw volgende web-API-ontwerp

Er zijn zoveel classificaties voor API's. Maar als het gaat om webcommunicatie, kunnen we twee belangrijke API-typen identificeren - Web Service API's (bijv. SOAP, JSON-RPC, XML-RPC, REST) ​​en Websocket API's. Maar wat betekenen deze eigenlijk? Laten we de wereld van webcommunicatieprotocollen induiken en bespreken hoe we uiteindelijk de beste API-mechanismen kunnen kiezen.

HTTP

HTTP is het onderliggende communicatieprotocol van World Wide Web. HTTP functioneert als een verzoek-antwoord protocol in het client-server rekenmodel. HTTP / 1.1 is de meest voorkomende versie van HTTP die wordt gebruikt in moderne webbrowsers en servers. In vergelijking met vroege versies van HTTP, zou deze versie kritische prestatie-optimalisaties en functieverbeteringen kunnen implementeren, zoals persistente en pipelined-verbindingen, chunked transfers, nieuwe koptekstvelden in de aanvraag- / antwoordtekst enz. Onder hen zijn de volgende twee headers zeer opmerkelijk, omdat de meeste moderne verbeteringen aan HTTP zijn afhankelijk van deze twee headers.

  • Keep-Alive header om beleid in te stellen voor langlevende communicatie tussen hosts (time-outperiode en maximaal aantal aanvragen per verbinding)
  • Upgrade header om de verbinding te schakelen naar een verbeterde protocolmodus zoals HTTP / 2.0 (h2, h2c) of Websockets (websocket)

Als je geïnteresseerd bent om te weten wat deze echt doen, heb ik alle belangrijke informatie voor je gedocumenteerd in het onderstaande artikel.

RUST UIT

De architecturale stijl, REST (REpresentational State Transfer) is veruit de meest gestandaardiseerde manier om de web-API's voor verzoeken te structureren. REST is puur een architecturale stijl gebaseerd op verschillende principes. De API's die voldoen aan REST-principes worden RESTful API's genoemd. REST API's gebruiken een verzoek / antwoordmodel waarbij elk bericht van de server het antwoord is op een bericht van de client. Over het algemeen gebruiken RESTful API's HTTP als transportprotocol. Voor dergelijke gevallen moeten opzoekingen GET-aanvragen gebruiken. PUT-, POST- en DELETE-aanvragen moeten respectievelijk worden gebruikt voor mutatie, creatie en verwijdering (vermijd het gebruik van GET-aanvragen voor het bijwerken van informatie).

HTTP-peiling

In HTTP Polling, peilt de client de server die om nieuwe informatie vraagt ​​door zich aan een van de onderstaande mechanismen te houden. Polling wordt tegenwoordig door de overgrote meerderheid van toepassingen gebruikt en gaat meestal met RESTful-praktijken. In de praktijk wordt HTTP Short Polling zeer zelden gebruikt en is HTTP Long Polling of Periodic Polling altijd de keuze.

  • HTTP Short Polling: eenvoudiger aanpak. Veel verzoeken worden verwerkt wanneer ze naar de server komen, waardoor veel verkeer wordt gegenereerd (gebruikt middelen, maar bevrijdt ze zodra het antwoord wordt teruggestuurd). Omdat elke verbinding slechts voor een korte periode open is, kunnen veel verbindingen in de tijd worden gemultiplexed.
00:00:00 C-> Is de cake klaar?
00:00:01 S-> Nee, wacht.
00:00:01 C-> Is de cake klaar?
00:00:02 S-> Nee, wacht.
00:00:02 C-> Is de cake klaar?
00:00:03 S-> Ja. Heb een jongen.
00:00:03 C-> Is de andere cake klaar?
  • HTTP Long Polling: één verzoek gaat naar de server en de client wacht op het antwoord. De server houdt het verzoek open totdat nieuwe gegevens beschikbaar zijn (deze zijn niet opgelost en bronnen worden geblokkeerd). U wordt onmiddellijk op de hoogte gebracht wanneer de servergebeurtenis plaatsvindt. Complexere en meer gebruikte serverbronnen.
HTTP Long Polling - Reactie wordt vastgehouden totdat server procesgegevens verwerkt (afbeelding van shyamapadabatabyal.wordpress.com)
12:00 00:00:00 C-> Is de cake klaar?
12:00 00:00:03 S-> Ja. Heb een jongen.
12:00 00:00:03 C-> Is de andere cake klaar?
  • HTTP Periodic Polling: er is een vooraf bepaalde tijdspanne tussen twee verzoeken. Dit is een verbeterde / beheerde versie van polling. U kunt het serververbruik verminderen door het tijdsverschil tussen twee aanvragen te vergroten. Maar als u onverwijld op de hoogte moet worden gesteld wanneer de servergebeurtenis plaatsvindt, is dit geen goede optie.
HTTP Periodic Polling - Verzoek wordt elke n seconden verzonden (Afbeelding van ibm.com)
00:00:00 C-> Is de cake klaar?
00:00:01 S-> Nee, wacht.
00:00:03 C-> Is de cake klaar?
00:00:04 S-> Ja. Heb een jongen.
00:00:06 C-> Is de andere cake klaar?

HTTP-streaming

HTTP-streaming - biedt een langlevende verbinding voor directe en continue gegevenspush (Afbeelding van realtimeapi.io)

Client doet een HTTP-verzoek en de server druppelt een antwoord van onbepaalde duur af (het is net als oneindig pollen) .HTTP-streaming is performant, gemakkelijk te consumeren en kan een alternatief zijn voor websockets.

  • Probleem: tussenpersonen kunnen de verbinding onderbreken (bijv. Time-out, tussenpersonen die andere verzoeken op round-robin-manier bedienen). In dergelijke gevallen kan het niet de volledige betrouwbaarheid garanderen.
00:00:00 OPDRACHTGEVER-> Ik heb cake nodig
00:00:01 SERVER-> Wacht even.
00:00:01 SERVER-> Cake-1 is bezig.
00:00:02 SERVER-> Cake-1 hebben.
00:00:02 SERVER-> Wacht op cake-2.
00:00:03 SERVER-> Cake-2 is bezig.
00:00:03 SERVER-> Je zult zeker genieten van cake-1.
00:00:04 SERVER-> Cake-2 hebben.
00:00:04 SERVER-> Wacht op cake-3.
00:00:05 OPDRACHTGEVER-> Genoeg, ik zit vol.

SSE (Server Sent Events / EventSource)

SSE - evenementen kunnen naar meerdere clients worden uitgezonden (afbeelding van javaee.ch)
  • SSE-verbindingen kunnen alleen gegevens naar de browser pushen. (communicatie vindt alleen plaats van server naar browser, browsers kunnen zich alleen abonneren op gegevensupdates afkomstig van de server, maar kunnen geen gegevens naar de server verzenden)
00:00:00 OPDRACHTGEVER-> Ik heb cake nodig
00:00:02 SERVER-> Cake-1 hebben.
00:00:04 SERVER-> Cake-2 hebben.
00:00:05 OPDRACHTGEVER-> Genoeg, ik zit vol.
  • Voorbeeldtoepassingen: Twitter-updates, aandelenkoersen, cricketscores, meldingen voor de browser
  • Probleem # 1: sommige browsers ondersteunen geen SSE.
  • Probleem 2: Maximaal aantal open verbindingen is beperkt tot 6 of 8 via HTTP / 1.1 (gebaseerd op browserversie). Als u HTTP / 2 gebruikt, is er geen probleem omdat één TCP-verbinding voldoende is voor alle aanvragen (dankzij multiplex-ondersteuning in HTTP / 2).

HTTP / 2 server push

  • Een mechanisme voor een server om activa (stylesheets, scripts, media) vooraf proactief naar de clientcache te pushen
  • Voorbeeldtoepassingen: feeds van sociale media, apps met één pagina
HTTP / 2 is een efficiënte transportlaag op basis van multiplexstromen (afbeelding van SessionStack.com) - Volgens IETF is een
  • Probleem 1: Tussenpersonen (proxy's, routers, hosts) kunnen ervoor kiezen om informatie niet naar de client te sturen zoals bedoeld door de oorspronkelijke server.
  • Probleem 2: Verbindingen worden niet voor onbepaalde tijd opengehouden. Een verbinding kan op elk moment worden gesloten, zelfs wanneer het pushproces van inhoud plaatsvindt. Eenmaal gesloten en opnieuw geopend, kan deze verbinding niet verder gaan waar hij was gebleven.
  • Probleem 3: sommige browsers / tussenpersonen ondersteunen Server Push niet.

WebSockets

Met WebSockets kunnen zowel de server als de client op elk gewenst moment berichten pushen zonder enige relatie met een eerder verzoek. Een opvallend voordeel bij het gebruik van websockets is dat bijna elke browser websockets ondersteunt.

WebSocket lost enkele problemen met HTTP op:

  • Bidirectioneel protocol - client / server kan een bericht naar de andere partij verzenden (in HTTP wordt het verzoek altijd door de client geïnitieerd en wordt het antwoord verwerkt door de server - waardoor HTTP een uni-directioneel protocol wordt)
  • Full-duplex communicatie - client en server kunnen onafhankelijk van elkaar tegelijkertijd praten.
  • Enkele TCP-verbinding - Na een upgrade van de HTTP-verbinding in het begin, communiceren client en server via dezelfde TCP-verbinding gedurende de levenscyclus van de Websocket-verbinding.
00:00:00 OPDRACHTGEVER-> Ik heb cake nodig
00:00:01 SERVER-> Wacht even.
00:00:01 OPDRACHTGEVER-> Oké, cool.
00:00:02 SERVER-> Cake-1 hebben.
00:00:02 SERVER-> Wacht op cake-2.
00:00:03 OPDRACHTGEVER -> Wat is deze smaak?
00:00:03 SERVER-> Vind je het niet leuk?
00:00:04 SERVER-> Cake-2 hebben.
00:00:04 OPDRACHTGEVER-> Ik vind het leuk.
00:00:05 OPDRACHTGEVER-> Maar dit is genoeg.
Websocket-verbinding (afbeelding van PubNub.com)

Voorbeeldapplicaties: IM / Chat-apps, Games, Admin frontends

Hoewel wordt gezegd dat websockets door elke browser worden ondersteund, kunnen er ook tussenpersonen uitzonderingen zijn:

  • Onverwacht gedrag bij tussenpersonen: als uw websocket-verbindingen door proxy's / firewalls gaan, is het u misschien opgevallen dat dergelijke verbindingen altijd mislukken. Gebruik altijd Secured Websockets (WSS) om dergelijke storingen drastisch te verminderen. Deze case wordt hier goed uitgelegd: hoe HTML5-websockets communiceren met proxyservers en ook hier: WebSockets, voorzichtigheid vereist !. Dus wees voorzichtig en bereid je voor om ze te behandelen door WSS te gebruiken en terug te vallen op een ondersteunend protocol.
  • Tussenpersonen die geen websockets ondersteunen: als om welke reden dan ook het WebSocket-protocol niet beschikbaar is, zorg er dan voor dat uw verbinding automatisch terugvalt naar een geschikte optie voor lang opvragen.

REST versus Websockets - Perf-test

Als u een prestatietest uitvoert voor REST en Websockets, kan het zijn dat Websockets beter presteren wanneer er hoge belastingen aanwezig zijn. Dit betekent niet noodzakelijkerwijs dat REST inefficiënt is. Mijn persoonlijke mening is dat het vergelijken van REST met Websockets hetzelfde is als het vergelijken van appels met peren. Deze twee functies lossen twee verschillende problemen op en kunnen niet worden vergeleken met een eenvoudige perf-test als deze:

In de eerste grafiek neemt de REST-overhead toe met het aantal berichten, omdat er zoveel TCP-verbindingen moeten worden gestart en beëindigd en omdat er veel HTTP-headers moeten worden verzonden en ontvangen. In de tweede grafiek zijn de incrementele kosten voor het verwerken van een verzoek / reactie voor een REST-eindpunt minimaal en wordt de meeste tijd besteed aan het initiëren / beëindigen van verbindingen en het honoreren van HTTP-semantiek. (Perf-test en analyse van arungupta.me)

U moet nu echter begrijpen dat websockets een geweldige keuze zijn om langlevende bidirectionele datastreaming vrijwel realtime af te handelen, terwijl REST geweldig is voor incidentele communicatie. Het gebruik van websockets is een aanzienlijke investering, daarom is het een overkill voor incidentele verbindingen.

Webhooks (voor communicatie tussen servers)

Als u gegevens van uw API wilt verkrijgen over het wijzigen van gegevens, moet polling de eerste optie zijn die u te binnen schiet. Maar als het gaat om communicatie tussen servers, kosten inefficiënties in polling ons veel (gemiddeld wordt 98,5% van de polls verspild).

Webhooks - eenvoudige manier voor het verzenden van gegevens tussen servers zonder langdurige polling-verbindingen (afbeelding van realtimeapi.io)

Webhooks zijn de redder voor dit probleem. Onthoud hier dat de communicatie meestal plaatsvindt tussen servers. Eerst registreert het afzenderknooppunt vooraf een terugbel-URL in het ontvangerknooppunt. Wanneer een gebeurtenis plaatsvindt aan de afzenderzijde, wordt de webhook geactiveerd en verzendt een gebeurtenisobject met nieuwe gegevens als een HTTP POST-verzoek naar de ontvangerknooppunten met behulp van callback-URL's die in elk daarvan zijn geregistreerd.

Het leuke is dat de serverbelasting voor zowel de afzender- als de ontvangerknooppunten drastisch kan worden verminderd met webhooks. Het zorgt voor een betere gebruikerservaring, terwijl uw ontwikkelaars uw service-eindpunten kunnen gebruiken voor betekenisvolle dingen zonder te verspillen aan polling.

Webhooks worden meestal gebruikt voor het verzenden van meldingen en statuswijzigingen tussen servers wanneer zich een gebeurtenis voordoet. Wanneer een gebruiker zich bijvoorbeeld afmeldt via een knopklik in e-mail, komt hij bij een server en vindt de gebeurtenis Gebruiker afmelden plaats, activeert deze gebeurtenis de overeenkomstige webhooks en melden zij alle servers / services die de gebruiker zich nu heeft afgemeld voor hun service (Afbeelding van kloudymail.com)
  • Voorbeeldtoepassingen: meldingen wanneer een nieuwe gebruiker zich registreert of een huidige gebruiker een bestaande profielinstelling bijwerkt
  • Probleem: ontwikkelaars vinden het moeilijk om webhooks in te stellen en HTTP-services te schalen.

Wat te gebruiken voor uw volgende API?

Welke techniek u moet gebruiken, hangt af van wat logischer is in de context van uw toepassing. Natuurlijk kun je een paar trucs gebruiken om het gedrag van de ene technologie met de andere te simuleren, maar het is meestal beter om de technologie te gebruiken die beter bij je communicatiemodel past als je hem bij het boek gebruikt.

HTTP / 1.1 versus HTTP / 2: dit zijn transportprotocollen. Mutiplexing-mogelijkheden in HTTP / 2 zijn geweldig, maar worden nog niet overal ondersteund. Zorg er in dergelijke gevallen voor dat u niet terugvalt van HTTP / 2 en HTTP / 1.1. Voor het overbrengen van gegevens is HTTP / 1.1 nog steeds een goede keuze.

RESTful API's: tot nu toe zijn RESTful API's goed voor webapplicaties. Maar er zijn discussies gaande over het verkennen van betere manieren. Een voorbeeld is dit concept - "RESTful API's vervangen door JSON-Pure". Ik hou van het idee, JSON is eigenlijk ontwikkelaarsvriendelijk en je kunt er wonderen mee doen. Maar weet je, dit zijn concepten aan het ontwikkelen.

JSON versus XML: gebruik JSON. Het is de trend en ook zo handig om mee om te gaan.

HTTP-peiling: dit is oud, maar nog steeds een geweldige keuze voor het omgaan met API's. Als uw gegevens regelmatig of in realtime veranderen, gebruik dan geen korte peiling, gebruik gewoon websockets, de betere technologie voor realtime. Gebruik altijd lange en periodieke peiling op de juiste manier (met REST-principes).

HTTP-streaming: dit is goed voor toepassingen zoals nieuws / sociale media-feeds, aandelen- / scoreborden, tweets enz. Maar in de praktijk gebruiken mensen websockets dan HTTP-streaming.

HTTP / 2 Server Push is geweldig voor het op een meer beheerde manier verzenden van resources naar de client. Maar alle tussenpersonen en browsers ondersteunen dit niet. Zorg ervoor dat je dergelijke fallbacks netjes aanpakt.

Door de server verzonden gebeurtenissen zijn een vrij nieuwe technologie die nog niet door alle grote browsers wordt ondersteund, dus het is nog geen optie voor een serieuze webapp op ondernemingsniveau (Ja, ik ben het ermee eens dat u deze technologie kunt laten werken).

WebSockets bieden een rijker protocol voor bidirectionele, full-duplex communicatie. Het hebben van een tweerichtingskanaal is aantrekkelijker voor zaken als games, berichten-apps, samenwerkingstools, interactieve ervaringen (inclusief micro-interacties) en voor gevallen waarin u realtime updates in beide richtingen nodig hebt.

Webhooks verschillen van alle bovenstaande technologieën omdat het een zeer specifiek probleem oplost. Als uw servers regelmatig en / of bidirectioneel moeten communiceren, kies dan voor websockets. Als uw servers incidenteel communiceren, gebruikt u REST-aanroepen. Als uw servers unidirectioneel moeten communiceren bij een gebeurtenistrigger, kies dan voor webhooks. Gebruik polling niet om wijzigingen in gegevens of status te controleren, het is zonde.

Enige tips?

️ Volmachten en tussenpersonen zijn gek. Ze zullen je pakketten opeten of een time-out krijgen onverwacht. Wees je daarvan bewust en ga er netjes mee om.

Secured Gebruik beveiligde transportprotocollen (HTTPS of WSS) om uw communicatie af te handelen. Dan hebben tussenpersonen minder impact op uw connecties. En het is veilig, weet je.

️ Ontwikkelaars zijn dol op webhooks. Maar zorg ervoor dat je het goed toepast.

️ U hoeft echt niet altijd de nieuwste technologie te omarmen, vooral wanneer u applicaties op ondernemingsniveau maakt. Zorg ervoor dat alle infrastructuur de technologie ondersteunt die u gebruikt. En als de infrastructuur uw technologie / architectuur niet ondersteunt, zorg er dan voor dat deze terugvalt naar een technologie die gewoon overal werkt en alles netjes werkt met verminderde mogelijkheden.

Referenties:

  • REST versus WebSocket-vergelijking en benchmarks
  • Short-polling versus Long-polling voor realtime webapplicaties?
  • Aan de slag met Realtime