Udvikler: Drop REST og HTTP til fordel for binær protokol

Illustration: Bigstock/Rost-9
Det er på tide at sætte gammeldags tekst-baserede protokoller på porten til fordel for effektive binære af slagsen, når det handler om mikrotjenester. Det mener tidligere Netflix-udvikler.

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Stig Christensen

Er det ikke lidt sjovt at kalde det "gammeldags tekst-baserede protokoller". De dukkede vel lige netop op efter at man i mange år havde brugt gammeldags "binære protokoller" og fandt det besværligt. Dette er jo bare den sædvanlig modreaktion, måske fordi der er plads til begge dele. "Gammeldags tekst-baserede protokoller" giver så meget mening fordi de er så lette at bruge og debugge for et hvert udviklingsmiljø.

  • 19
  • 2
Hans Nielsen

"Blandt salgspunkterne for REST var, at protokollen kunne læses af mennesker. Men dårlig læsbarhed for en protokol "

Og sådan skal det vel helst også være.
Det er langt svære for et menneske at lære at læse forskellige maskinkode, mens det er "let" for en maskine at oversætte en tekst til maskinkode/protokol. Det er hvad enhver compejler eller fortolker gør.

Der er ikke mange som programmere i maskinkode, måske lidt assembler. Og det er der en god grund til. Det er svært og tungt.

  • 1
  • 3
Hans Henrik Happe

Man kunne jo også tage bruger brillerne på. Hvorfor skal jeg som menneske straffes med en langsom brugeroplevelse, drænet batteri og varm laptop, bare fordi udviklere er blevet lullet ind i den opfattelse at tekst er godt. Tekst er jo også bare en fortolkning af binær data.

Pointen er netop at at man med de rigtige værktøjer kan oversætte frem og tilbage, men når maskiner skal snakke sammen effektivt så er tekst bare ekstra båndbredde, cycles, plads og tid.

  • 8
  • 2
Martin Sørensen

Det er utroligt rart under udvikling og debugging at det er muligt for mennesker at læse den rå kommunikation og i de fleste tilfælde betyder den ekstra overhead ikke så meget, men lige netop på helt små enheder til bl.a. IoT, der er der en del at hente ved at gå over til en mere optimal binær protokol.

Findes der ikke en gylden middelvej? Altså en protokol som kan overføres i ren tekst og stadig være letforståelig, men som også har en binær repræsentation som er mere optimal ifht. kodestørrelse og hastighed? Her er det så vigtigt at de to har en 1:1 relation så man kan stole på at når det virker med tekstversionen så virker det også når man skifter til den binære version. Så kan man udelade den del af koden som fortolker tekstversionen fra den færdige version af de dimser man leverer.

At have en 1:1 relation mellem de to sætter naturligvis nogle begrænsninger på syntaksen af den binære variant, men hvis man bare kan komme nogenlunde tæt på en optimal performance så er det også værd at gå efter vil jeg mene.

Enhederne behøver ikke nødvendigvis indeholde kode der kan fortolke tekstvarianten direkte da oversættelsen så kan foregå i det debug-værktøj man bruger.

  • 3
  • 0
Ivan Skytte Jørgensen

på helt små enheder til bl.a. IoT


Jeg arbejder med zigbee. Der har jeg maksimalt 56 bytes payload, afhængigt af hvor mange hops der er til destination.

Findes der ikke en gylden middelvej? Altså en protokol som kan overføres i ren tekst og stadig være letforståelig, men som også har en binær repræsentation som er mere optimal ifht. kodestørrelse og hastighed?


Den eneste, som jeg er stødt på, er BSON, som er binær representation af JSON. Ulemper er at BSON faktisk fylder mere end JSON. Fordelen er at man kan hoppe over uninteressante dataklumper, hvilket ikke kan lade sig gøre i tekst.

Mht. til et almen kompakt binært format så er der PER-encoding af ASN.1. En boolean fylder 1 bit. Men formatet er ikke just sjovt at arbejde med.

  • 2
  • 0
Lars Tørnes Hansen

Der er ikke mange som programmere i maskinkode, måske lidt assembler. Og det er der en god grund til. Det er svært og tungt.

Assembler er en tekst repræsentation af maskinkoden.

I tilfældet tekst vs binære protokoller, så er - når man bruger dit metafor - så er assembler en tekst protokol, og maskinkoden den binære protokol.

Jeg er enig i artiklens påstand om at:

... 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.

En assembler og en diassembler er værktøjer til at arbejde med assembler og maskinkode.

[Wireshark][https://www.wireshark.org/] er et fremragende værktøj til at arbejde med tekst baserede såvel som binære (netværks-) protokoller.

Wireshark, en assembler, og en diassembler er værktøjer som virker aldeles glimrende til deres opgaver, så jeg synes ikke at dit assembler, maskinkode metafor argument holder.

  • 4
  • 0
Thomas Søndergaard
  • 3
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize