2019. január 8. 4 perc olvasás
Néhány nappal ezelőtt a Quora „megkért”, hogy válaszoljak valakinek, aki megkérdezte, hogy az „AWS API Gateway más protokollt támogat, mint a REST”. A kérdés fogalmi hibája ellenére - azt hiszem, tudja, mi az - nagyon gyorsan válaszoltam rá, de Sergio hamarosan, és részletesebben is beszélni fog az API Gateway-ről. Szóval tarts velünk! A helyzet az, hogy ez a kérdés inspirált arra, hogy megírjam a mai bejegyzést, és rövid összehasonlítást végezzek a REST (HTTP) és a WebSocket között.
Több mint „REST vs WebSocket” összehasonlítás, ez egy HTTP és a WebSocket (ws) összehasonlítás. Nos, amire jól emlékszel, a REST (reprezentatív állapotátvitel) az építészeti tervezés mintája vagy stílusa, és nem szállítási protokoll. A HTTP protokoll a REST architektúra megvalósítása.
Nagyon rövid és összefoglaló - további információkat itt talál, vagy itt, a REST API egy olyan szabályhalmaz, amely lehetővé teszi a webalkalmazások közötti kommunikációt. A REST a HTTP protokollt és számos szolgáltatását használja az API felépítés részeként. Valójában valaki régen azt mondta, hogy "A REST a web és a web a REST". Egyetért vagy nem, de ma ez a leggyakrabban használt stílus.:)
A Websocket egy olyan kommunikációs protokoll, amely ugyanazon TCP kapcsolaton keresztül "full-duplex" kommunikációs csatornákat biztosít. Ugyanaz a koncepció, mint a klasszikus UNIX foglalatokban, de az interneten, és azzal a gondolattal, hogy megkönnyítse az adatok valós idejű továbbítását a szerverről és a szerverre. Kétirányú kommunikációként a kiszolgáló a kapcsolatot közvetlenül az ügyfélnek küldheti el az információt. Mint jól tudod, a REST nem teszi meg könnyen. Bár nagyon erős keretrendszerek vannak a piacon, amelyek tudják, hogyan kell valós időben kezelni a REST-et és a háttérprogramokat.
Mint már korábban említettük, a REST egy architektúra stílus, a WebSocket pedig egy protokoll, ezért van értelme, ha összehasonlítjuk a HTTP-t a WebSocket-kel. Íme néhány különbség:
A WebSockets segítségével egyszerű karakterlánc-üzeneteket küld az adatokkal a szerverre, és a szerver feldolgozza az adatokat és a válaszokat. A kommunikáció hatékonyabb, mint a HTTP, ha az üzenet méretére és különösen a nagy üzenetek sebességére összpontosítunk, mivel például a HTTP-ben minden egyes kérésnél el kell küldenie a fejléceket. Ez bájtokat ad hozzá. A REST-ben is az URL-ekben és a HTTP-módszerekben vannak erőforrásai. Ami azt jelenti, hogy minden kérésre választ kap.
Jó ötlet lehet David Luecke benchmarkingját megvizsgálni a HTTP és a WebSockets teljesítményének összehasonlításához. Látni fogja, hogy több mint 50 egyidejű kérés esetén a Websockets 50% -kal gyorsabb lehet, mint a HTTP! Ez azt jelenti, hogy sok esetben és a projekt igényeitől függően a WebSockets gyorsabb lehet, mint a hagyományos HTTP API-k.
A másik jelentős különbség a kettő között számomra az, hogy a WebSocketek állapotprotokollok, míg a HTTP kapcsolatok hontalanok. Ez azt jelenti, hogy a WebSockets olyan kapcsolatot hoz létre, amely életben marad a kiszolgálón, amíg a foglalatot nem zárják le, és az üzeneteket kétirányúan cserélik. Míg a HTTP-kapcsolatoknál, amelyekben a kérés választ jelent - érvényes vagy nem -, a különböző szerverekről történő hozzáférés nem szakítja meg a működésüket, ami az én szempontomból ideális, például mikrohelyzetekhez. Nos, bármely szerver képes kezelni bármilyen kérést, és nincs szükség a megosztott állapotok szinkronizálására, az adatbázis kivételével.
Befejezésül, és még ha lehetséges is, úgy gondolom, hogy a 100% -os WebSocket rendszer megvalósítása rossz ötlet lehet abban az értelemben, hogy olyan funkciókat kell megvalósítania, amelyek már léteznek a REST és a HTTP fájlokban. Újra feltalálni a kereket? Tehát miért ne használná a WebSocketeket valós idejű adattranzakciókhoz - például egy csevegéshez -, és az ellenkező esetben a REST-et?
Úgy gondolom, hogy a legjobb opció kiválasztásakor fontos figyelembe venni bizonyos részleteket is, például a HTTP-kapcsolatoknál, a böngésző korlátozza az egyidejű kérelmek számát, de nincs korlátozás azon üzenetek számára, amelyeket a WebSocket által végzett kapcsolat küldhet vagy fogadhat. Javaslom továbbá az adatátvitel, a betöltési idő és a méretezhetőség mutatóinak figyelemmel kísérését. És hogy mindent sokkal jobban ellenőrizhessünk, miért nem hozhatunk létre olyan rendszereket, amelyek lehetővé teszik az egyes helyzetekhez legmegfelelőbb szállítási protokollok egyszerű kiválasztását?
Milyen esetekben használ Websocketeket HTTP helyett, vagy fordítva?