Web-ontwikkelaars op zoek naar eenvoudiger protocollen

Als het aan standaardisatie-organisaties OASIS en W3C lag, dan bouwden we onze web services op SOAP, UDDI en WSDL. De praktijk ziet er echter heel anders uit. De UDDI directories zijn niet van de grond gekomen. XML-code bevat veel te veel overtollige informatie. En SOAP-envelopen zijn vaak groter dan de data die ze bevatten. Architecten en ontwikkelaars trekken hun eigen plan.

Bij Web Services denken we gelijk aan drie standaarden: SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) en UDDI (Universal Description Discovery and Integration). Die laatste levert een directory-dienst waarmee aanbieders van web services zichzelf bekend kunnen maken. Het formaat van hun elektronische diensten is vastgelegd in een WSDL-document. En het aanroepen van web services — dus ook die van UDDI — verloopt via SOAP-berichten.

Het idee achter deze opzet is dat gedistribueerde software-onderdelen meer dynamisch met elkaar verbonden zouden worden. Zo kan een web-applicatie aan de achterkant door de beheerder heel makkelijk van een andere payment-processor worden voorzien. Een web-shop kan eenvoudig worden uitgebreid met de productcatalogus van een nieuwe toeleverancier. En voor de fulfillment kan direct worden geschakeld tussen verschillende dienstverleners.

Remote Procedure Calls

Omdat niet alleen alle communicatie in XML-formaat (Extensible Markup Language) verloopt maar ook de web service interfaces zelf in XML zijn gedefinieerd, zouden dergelijke aan- en afkoppelingen ook geautomatiseerd kunnen verlopen. In de praktijk is daar echter weinig van terecht gekomen. De publieke UDDI Business Registry (UBR) is door initiatiefnemers IBM, Microsoft en SAP jaren geleden al de nek omgedraaid.

Op dit moment zijn web services dan ook vooral een moderne manier voor programmeurs om gedistribueerde applicaties in elkaar te zetten. Functie-aanroepen via SOAP zijn niet fundamenteel anders dan die via RPC (Remote Procedure Call). SOAP wordt meestal gebruikt om XML-berichten te transporteren over HTTP (Hypertext Transfer Protocol). De WS-I (Web Services Interoperability Organization), opgericht door onder andere IBM, Microsoft, BEA, SAP, Oracle, HP en Intel, raadt aan daarvoor de beveiligde vorm (HTTPS) te gebruiken. Die technologie wordt al veel gebruikt in de online wereld, met name voor de beveiliging van het verkeer tussen web-browser en -server ("het slotje").

RPC maakt gebruik van TCP/IP en bevindt zich dus op hetzelfde niveau als HTTP, Telnet en FTP (File Transfer Protocol). Andere bekende protocollen/interfaces met vergelijkbare functionaliteit zijn Java RMI (Remote Method Invocation), CORBA (Common Object Request Broker Architecture), XML-RPC (XML over HTTP; de voorloper van SOAP) en JSON-RPC.

JSON

Die laatste lijkt erg op XML-RPC, zij het dat nu JSON (JavaScript Object Notation) wordt gebruikt om vraag en antwoord te coderen. Het grootste voordeel van XML is namelijk tegelijkertijd het belangrijkste bezwaar: De data is direct te lezen door de gebruiker, maar bevat een heleboel overbodige herhaling. Omdat web-browsers en -servers hun onderlinge verkeer veelal comprimeren, is dat niet noodzakelijk een probleem voor de netwerk-belasting. Apache, de meeste gebruikte web-server, biedt daarvoor bijvoorbeeld de deflate- en gzip-modules.

JSON biedt echter hetzelfde voordeel van de directe leesbaarheid, maar in een veel compacter vorm. Maar belangrijker nog is dat het formaat gebaseerd is op de datastructuren van de JavaScript-taal (ECMAScript). Met de opkomst van Web 2.0, waarbij de inhoud van HTML-pagina's dynamisch wordt geupdate, heeft ook JSON een grote vlucht genomen. De JSON-data die via AJAX-aanroepen (Asynchronous JavaScript and XML) wordt binnengehaald, kan door JavaScript-programmaatjes direct worden verwerkt en in de HTML DOM (Document Object Model) worden ingepast. Zo kunnen delen van een web-pagina worden ververst zonder dat de hele pagina daarvoor opnieuw geladen moet worden.

Met JSON is een volgende stap gezet in de vereenvoudiging en toegankelijkheid van document-standaarden. XML was immers al een vereenvoudiging van het zeer uitgebreide en complexe SGML (Standard Generalized Markup Language), dan op zijn beurt weer een vereenvoudiging is van het oeroude GML (in de jaren '60 bedacht door IBM). JSON wordt inmiddels als alternatief dataformaat naast XML aangeboden door Google, Yahoo en eBay. Amazon biedt een ingebakken XSLT-engine (Extensible Stylesheet Language Transformation) waarmee de XML-output aan server-zijde naar elk gewenst formaat vertaald kan worden, dus ook naar JSON.

REST

Een vergelijkbare vereenvoudiging zien we ook in de aanroepen van web services. SOAP-berichten bestaan uit een envelope met daarin (meestal) een XML-datastructuur. Met name de vraag om informatie is vaak maar klein in omvang ten opzichte van die envelope. Omdat SOAP meestal over HTTP wordt getransporteerd, kunnen de parameters van de vraag ook in de URI (Uniform Resource Identifier) worden opgenomen, op exact dezelfde manier waarop web-browsers tijdens het surfen parameters aan de server doorgeven. Gebruikers kunnen een dergelijke web service dan ook direct vanuit hun browser benaderen. Naast de standaard SOAP-interface bieden Amazon en eBay ook deze toegangsmethode aan. En met succes: slechts een minderheid van de ontwikkelaars gebruikt SOAP om de Amazon-diensten te benaderen.

Deze efficiënte manier van werken draagt de naam REST (Representational State Transfer). Het refereert naar een gedistribueerde client-server architectuur waarin objecten via een netwerk-protocol (in ons geval HTTP) kunnen worden benaderd en gemanipuleerd. Dit in tegenstelling tot SOAP, een protocol waarbij HTTP alleen als drager fungeert. Daarbij worden bevragingen en bewerkingen op een hoger niveau per toepassing opnieuw gedefinieerd. Zo zijn de HTTP-methoden GET en POST (voor het respectievelijk opvragen en creëren van objecten) goed bekend. De PUT- en DELETE-opdrachten (voor het respectievelijk veranderen en verwijderen van objecten) worden echter veel minder toegepast. Niet zelden wordt de GET-opdracht misbruikt voor het verwijderen van objecten, terwijl de HTTP-standaard vereist dat die geen veranderingen op de server tot gevolg mag hebben (een veilige opdracht, zonder bij-effecten).

HTML5

Met de introductie van HTML5 ondersteunen de web-formulieren naast de GET- en POST-opdrachten nu ook PUT en DELETE. Dat biedt web-ontwikkelaars de mogelijkheid om HTTP te gebruiken zoals het bedoeld was. De populariteit van JSON en REST ten koste van XML en SOAP laat echter zien dat architecten en ontwikkelaars de technologie uitzoeken die het best aansluit bij hun behoefte. En als dat nodig is, ontwikkelen ze zelf een nieuwe "standaard".