Serialseb, eller Sebastien Lambla som han egentligen heter, körde en dragning om ReST och hur dessa APIer utvecklats sedan 1991 när webben för första gången såg dagens ljus.

Han inledde med en kort historielektion där vi fick reda på vad 1.0 och 2.0 av ReST innebär och vad de har för nackdelar. 1.0 är originalet med JSON och HTTP anrop och 2.0 är när man gick över på "hypermedia", ett sätt att stödja mer automatisk utforskning av APIer, t ex genom att ge ut länkar till liknande resurser i ett API-svar (se t ex HATEOS)

3.0 däremot kommer, enligt Sebastien, bli mer uniformt mellan APIer så att man inte behöver en klient per API utan istället att man kan standardisera hur t ex felkoder och länkar skickas ut. Två exempel på saker som förekommer i nästan alla ReST-APIer, men som skiljer mellan dem, är vad som kallas ett "home document" dvs. "förstasidan" för APIet där vilka operationer som finns är listade. Det andra är "error details", alltså hur fel i APIet beskrivs för klienten. Det finns ett antal försök redan nu för att försöka standardisera dessa, t ex HAL och Siren. Det senare ger även stöd för hur requester mot APIet ska se ut vilket innebär att vi kan ha ännu mindre kod som måste skrivas för varje ReST-integration. 

Det finns redan idag stöd för länkar i HTTP headers. Dessa beskrivs med en URI samt en "rel" som beskriver vilken relation den har till det dokument som precis laddats ner. En ny sån som kommit är "preload" som säger till klienten att börja ladda ner den så fort det bara går för den kommer vara av användning senare i dokumentet. I kombination med den nya statuskoden "103" ("Early hints") kan data laddas ännu snabbare då servern kan skicka ut dessa preload-headers innan hela svaret är färdigskapat.

Några saker som kommer framöver som Sebastien pratade om är t ex HTTP/2 och multiplexing, där en klient kan skicka flera requester över samma TCP-anslutning och servern kan svara i vilken ordning den vill. Detta snabbar upp dataöverföringen rejält eftersom det oftast är långsamt att starta en ny TCP-anslutning. Liknande har funnits sedan tidigare men då var servern tvungen att svara på anropen i samma ordning de kom in, vilket så klart gör att det kan bli kö om någon tung databasfråga eller liknande ska köras. HTTP/2 kommer även vara helt binärt vilket gör att det både går snabbare för en dator att tolka informationen och att den blir mindre så att det går fortare att skicka den. 

Som om inte HTTP/2 skulle vara snabbt nog har Google även börjat exprimentera med en teknik de kallar QUIC (Quick UDP Internet Connections), ett sätta att köra webben över UDP istället för TCP. Även detta borde snabba upp webben rejält. 

Comment