De grote impact van REST op software architectuur
We're Cerios

De grote impact van REST op software architectuur

Geschreven door Remco Hoetmer op 6 maart 2014

De voordelen van REST-style architecturen zijn lange tijd slecht onderkend geweest; men associeerde REST vaak met JSON en free-format en dat valt juist voor de enterprise ongelukkig uit. Toch is de opkomst ervan onstuitbaar want de eenvoud en inzichtelijkheid geeft grote voordelen in productiviteit.

Het bleef onopgemerkt omdat de technologie nog wel hetzelfde bleef: de eenvoud van de benadering werd niet begrepen. Voorbeeld: programmeurs gaven aan SOAP-functies een JSON body en andere HTTP URL en noemde dat ten onrechte REST. Echter, beheersing van de complexiteit blijft de grootste uitdaging binnen IT architectuur. Inmiddels hebben programmeurs de juiste REST implementatie ontdekt, en kunnen de voordelen ervan daadwerkelijk worden benut.

Een van de belangrijkste onderdelen van ICT architectuur is communicatie tussen componenten. Globaal bekeken zijn veel architecturen gebaseerd op het principe van volledige integratie: deelcomponenten zijn een onlosmakelijk onderdeel van het gehele. Als een component functionaliteit van een andere component nodig heeft, dan roept zij een functie ervan aan door middel van een RPC-call. Dat heeft nadelen: als een component niet beschikbaar is of als zij verandert, dan heeft dit gevolgen voor het hele systeem. Concepten als asynchroniciteit en autonomie geven weliswaar een flinke verbetering, maar lossen het wezenlijke probleem niet op.

De REST-style doet dat anders. Deze vindt zijn inspiratie in het Internet: het HTTP protocol zorgt ervoor dat miljarden mensen met elkaar kunnen communiceren, ook al vallen bepaalde systemen om de haverklap om, en wijzigt de inhoud van de websites voortdurend. En ook al blijft er vaak verouderde informatie op staan.

Bij de REST-style worden Internet principes toegepast op gegevensuitwisseling tussen systemen en deze andere benadering geeft grote voordelen.

Het uitgangspunt van REST is dat componenten “weergaven” van resources uitwisselen. Neem als voorbeeld van een resource een winkelwagentje met producten die een gebruiker heeft geselecteerd. Een HTML pagina is een weergave van het winkelwagentje. XML en JSON zijn een andere weergaven van dezelfde resource - weergaven die goed door computers kunnen worden geïnterpreteerd. Bij REST bepaalt de aanvrager welke weergave hij ontvangt. Met de verkregen data kan weergaven van gerelateerde resources worden opgevraagd, of van meta-data, of extra uitleg, enzovoort. Dat kan omdat de weergaven - en dat is typisch REST - boordevol hyperlinks zitten. Met andere woorden: REST werkt net zo eenvoudig en flexibel als dat we zelf aan het browsen zijn.

Op zich lijkt het niet zo’n heel erg grote stap in vergelijking met SOAP. Maar waarom is het zo’n vooruitgang? Het antwoord zit in de principes van REST.

Vaste metadata (uniforme interface)
Dit principe vereist dat metadata - waaronder semantische gegevens - op een uniforme manier naar buiten toe worden ontsloten (op HTTP protocolniveau) en niet binnen het bericht blijft. Bijvoorbeeld: de URL identificeert de resource, een HTTP header geeft aan wanneer deze voor het laatst is veranderd.

Dit principe stelt de generiek infrastructuur in staat om applicaties te verlichten van concerns als caching, monitoring, fail-over op een veilige manier. Zij leest op een eenvoudige manier de berichtkenmerken uit en kan overeenkomstig reageren. Bijvoorbeeld: het kan een resource cachen als deze veelvuldig wordt opgevraagd.

Stateless
Een state is een gegeven van de aanvrager diew op de server wordt bijgehouden. States beperken het opschalen van het gebruik van de component.

REST vereist dat componenten stateless zijn. Dit is ook van toepassing op transacties: resources kunnen dus niet deelnemen een transactie van de aanvrager.

Self-descriptive API
Hoewel er vaak wordt gestreefd naar self-descriptive API's, blijkt realisatie moeilijk. REST implementaties weten dit wel praktisch in te vullen (met name door flexibiliteit in formaten). In de eerste plaats profiteren ontwikkelaars hiervan. Daarnaast opent self-descriptive API's de mogelijkheid van dynamische verwerking. Voorbeeld: een invoerscherm dat dynamisch wordt opgebouwd op basis van metadata van resources.

Multimedia
Multimedia slaat op flexibiliteit in berichtenformaat. Net als bij browsen over Internet staat het formaat van de berichtuitwisseling niet vast: een afbeelding kan verschillende formaten aannemen. De browser weet zelf hoe het de afbeelding (hetzij in gif, jpeg, png) moet weergeven, het protocol schrijft dat niet voor.

Ook kan er gebruik worden gemaakt van content negotiation. Hierbij geeft de aanvrager aan in welk formaat (HTML, JSON) het de gegevens wil ontvangen.

Dynamisch objectenmodel
De server geeft de state van de resource aan door middel van hyperlinks. Dit krachtig middel is een manier van servers om veranderingen aan te geven. Voorbeeld: In geval van het winkelwagentje: er is een hyperlink "legen winkelwagen" indien er nog niet is afgerekend. Maar bij een afgerekend winkelwagentje is deze link niet meer aanwezig. Net als op HTML pagina’s.

De kracht van REST ligt enerzijds in de consistente en gezamenlijke toepassing van de principes. Maar daarnaast speelt er iets anders: REST is in staat om om soepel te gaan met de dynamiek van systemen op langere termijn: gebruik van andere media, andere gegevensdefinities, andere APIs. Bij de introductie van REST was dit een belofte, maar inmiddels hebben de concepten zich vertaald in praktische ontwerpkennis, tooling en operationele systemen. Er is veel ervaring mee opgedaan.

Dat wil niet zeggen dat REST voor alle vragen de beste oplossing biedt. Ontwikkeling van duurzame software blijft onverminderd complex: zaken als versioning, uitbreidbaarheid, fout-tolerantie zijn notoir lastig en er blijven trade-offs. Maar de REST style biedt wel de handvaten om hier grip op te krijgen. Door de communicatie inzichtelijk en eenvoudig te houden.