REST – XML-beskeder over HTTP-protokollen – er blevet de facto-standarden for kommunikation mellem mikrotjenester. Men ikke alle synes, at det er en god ting. Faktisk er det temmelig skidt.
Det mener Robert Roeser, som er direktør og medstifter af firmaet Netifi, der er et offspring af Netflix. Det firma udviklede protokollen RSocket sammen med tilhørende open source software, og det er det, som Netifi udvikler videre på.
REST blev i Robert Roesers syn implementeret som et hack oven på HTTP. Blandt salgspunkterne for REST var, at protokollen kunne læses af mennesker. Men dårlig læsbarhed for en protokol handler blot om ringe værktøjer, der kan forbedres, skriver han i et indlæg på udviklerbloggen Infoq.
»Blandt de ting, vi ønsker os i en protokol, der er designet til kommunikation mellem mikrotjenester, er binær serialisering, tovejs kommunikation, multiplexing og evnen til at udveksle metadata.«
Udviklere ønsker også muligheden for at processere data, som det ankommer, altså muligheden for at streame data. Det betyder igen et behov for flow-kontrol.
Ifølge Robert Roeser er svaret, ikke underligt, RSocket, som er designet med de førnævnte krav for øje.
Binære programmer kræver binære protokoller
Da REST dukkede op på horisonten i 2000, var det et bud på en afløser til værre alternativer, såsom SOAP, Javas RMI, CORBA og Javas serverkomponenter EJB.
I denne periode dominerede monolitiske serverprogrammer, og det meste eksterne trafik var til browser-klienter. Her passede REST godt ind.
Den tidlige bevægelse mod mikrotjenester, eller finkornet SOA, som det også kaldes, skyldtes et behov for at skalere den monolitiske applikation.
Ved at skære applikationerne i bidder, blev det muligt at betjene flere brugere med rimelige svartider. Applikationerne kunne udrulles på tusindvis af servere, og senere på virtuelle maskiner. REST var den protokol, man havde til rådighed, så det var den, man brugte.
Robert Roeser synes det er underligt, at man bruger programmer kompileret til mikrokode eller bytekode, men ikke benytter binære protokoller, som programmerne er sat i verden for at arbejde med.
Det er tåbeligt, synes han, at omskabe bits til JSON-strenge, der sendes over netværket, for siden at ende som bits igen på modtagerens side. Der er også ydelsesmæssige problemer forbundet med at parse de tekstbaserede meddelelser.
Hvilken protokol skal man vælge?
Nogle vil mene, at HTTP/2 passer bedre til REST end den tidligere version af web-protokollen. Den understøtter blandt andet streaming, men dog kun i forbindelse med push-meddelelser fra serversiden. Det er heller ikke muligt at styre flowet, som det kræves i forbindelse med applikationer.
En anden protokol, der er oppe i tiden, er ifølge Robert Roeser gRPC, som minder om SOAP. Den bygger på Googles binære Protocol Buffers, i stedet for XML. Men protokollen består af et miskmask af HTTP/2, specifikke headers og specielt udformede URL'er, hvilket er bøvlet, ifølge synspunktet. Protokollen understøttes heller ikke af browsere.
Robert Roeser mener, at RSocket derimod opfylder behovene for dagens mikrotjenester. RSocket fungerer lige så godt på serversiden som i browseren, via den underliggende Websocket-protokol.
RSocket er i øjeblikket på vippen af version 1.0 Release Candidate. Udover Websocket-protokollen understøttes også helt almindelig TCP til transport, samt andre protokoller. Der findes open source-implementeringer af protokollen i Java, Javascript, C++ og Kotlin.

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.