REST en de datakoppeling

Eerder schreef ik over de verdediging van de RESTful architectuur door Steve Vinoski.

In dit artikel gaat Steve Vinoski in op het argument dat de standaardisatie van REST interfaces weliswaar standaardisatie op interface nivo oplevert, maar dat het probleem vervolgens wordt verplaatst naar de applicaties, waar de data die met de HTTP-call meekomen, moeten worden geprojecteerd op de "echte" datastructuren.

De RPC/SOAP/WS-*-route probeert die "echte' datastructuren tot een standaard te maken over webservices en componenten heen. Op die manier wordt getracht het Web 'transparant' te maken voro (object-georiënteerde) programmatuur.

Vinoski's argumentatie komt neer op het volgende:
1. RPC/SOAP/WS-* bestrijdt het minder urgente probleem. Wat je nodig hebt voor Web-computing is een protocol wat het mogelijk maakt rekening te houden met schaalbaarheid, latency, caching, etc. REST/HTTP doet dat, door de standaardisatie van methods (GET, PUT, etc), RPC/SOAP/WS-* niet door de proprietary methods.
2. De voordelen van data-standaardisatie werken niet op het Web. Binnen één programma gaat dat wel goed, maar de problemen beginnen al bij een paar componenten die data-structuren delen. Bij deling van data-definties over het Web, over de grenzen van bedrijven en systemen heen, is het een illusie te denken dat er geen vertaling naar de "echte; structuren hoeft plaats te vinden.
3. Juist het feit dat REST het netwerk NIET transparant maakt, maakt REST ontwikkeling makkelijker en robuuster. REST gebruikt de grenzen tussen client en server expliciet: de client krijgt van de server een representatie, en houdt zelf zijn state bij. Dat is duidelijk, helder, makkelijk te bouwen, en robuust.

Ik vind het verhaal van Vinoski overtuigend, in ieder geval waar het gaat om ontwikkeling voor het Web. Binnen de muren van een bedrijf ligt het genuanceerder, maar hoe lang nog zullen we services maken waarvan we zeker weten dat ze alleen in de context van het eigen bedrijf worden gebruikt?

Wel één kanntekening: Vinoski zegt eigenlijk: laten we niet proberen één standaard datastructuur voor bv Employee te hanteren, want dat lukt toch niet. OK. Maar als twee systemen door middel van een webservice communiceren over een Employee, moet wel duidelijk zijn wat een Employee is, wat de betekenis van de attributen is, enzovoort.

Er moet op semantisch gebied dus wel degelijk een overeenstemming zijn, ook als die er op technisch gebied niet is. Vinoski mompelt wat over metadata, maar mompelen lost dit natuurlijk niet op.

Voor het goed werken van webservices inderdaad geen gemeenschappelijk datamodel nodig, laat staan overeenstemming over de technische datastructuren, maar wel een gedeeld semantisch model. Dat is natuurlijk bijna hetzelfde als een gedeeld data- of object-model. Wil dat nou zeggen dat we eerst maar een wereldwijd semantisch model moeten gaan zitten maken, voordat we met het Web en SaaS aan de gang kunnen?

Nee, natuurlijk niet. Zo moeilijk is die semantiek niet, en ik denk dat dat gedeelde model nu al aan het ontstaan is. En als het er eenmaal is, zou je er ook in je interfaces gebruik van kunnen maken.

Een soort semantisch resource-model. Heerlijk......