Follow Us on Twitter

Webservices via REST

Maart 2005 - Webservices worden steeds meer gebruikt om applicaties gedistribueerd met elkaar te laten communiceren. Webservices maken B2B-communicatie eenvoudiger en helpen ‘legacy’ back-office applicaties te integreren in nieuwe toepassingen. De aanroep van webservices gebeurt over het algemeen met SOAP berichten, een relatief complexe standaard. In dit Whitebook gaan we in op REST, een eenvoudiger alternatief voor SOAP dat recent in de aandacht is gekomen.

Service Oriented Architecture

Er wordt meer en meer gewerkt met een Service Oriented Architecture (SOA) als architectuur voor het koppelen van verschillende systemen, die ofwel fysiek ofwel logisch van elkaar zijn gescheiden. Webservices zijn een veel gebruikte manier om een SOA in te richten. (Alternatieve methodieken maken gebruik van Java RMI of XML-RPC). Webservices zijn nog interessanter geworden met de introductie van BPEL (Business Process Execution Language, zie ons Whitebook van juni 2004).

Webservices in een vogelvlucht

Bedrijfsapplicaties kunnen middels één of meer webservices direct - dus zonder interactieve tussenkomst - met elkaar communiceren, gegevens uitwisselen en op afstand bepaalde programma's modules (procedures en functies) activeren.

Om webservices te gebruiken wordt meestal gebruik gemaakt van de volgende drie standaarden:

  • UDDI (Universal Description, Discovery and Integration);
    Een register (soort telefoonboek) waar webservices in kunnen worden geregistreerd en worden opgezocht.
  • WSDL (Webservice Description Language);
    Omschrijving van een of meerdere webservices.
  • SOAP (Simple Object Access Protocol);
    Het protocol voor communicatie tussen de applicaties.

Op basis van UDDI wordt gevraagd welke webservices beschikbaar zijn. WSDL geeft vervolgens de juiste wijze aan waarop de webservice kan worden aangeroepen. De daadwerkelijke communicatie vindt vervolgens plaats via SOAP.

Wat is REST?

REST staat voor Representational State Transfer. Het is een manier om webservices te creëren op basis van de bestaande en eenvoudige bouwstenen van het internet. SOAP is vervangen door URL's voor adressering en de HTTP methodes (GET, POST, DELETE en PUT) voor het aanroepen van de service. UDDI en WSDL zijn trouwens nog steeds nodig.

Iedere programmeertaal die momenteel toepasbaar is om dynamisch met HTTP om te gaan geschikt is voor het gebruik van REST. Hiermee is bijvoorbeeld ook de mogelijkheid ontstaan om op een simpele manier een PL/SQL applicatie (HTML DB of MOD PL/SQL) op te nemen in een SOA architectuur.

Een overzicht van alle data elementen van REST staat in de tabel hieronder.

REST Data Element

Voorbeeld internet

resource

Het conceptuele object van een hypertext reference

resource identifier

URL, URN

representation

XML, HTML, JPEG image

represenation metadata

media type, last-modified time

resource metadata

source link, alternates, vary

control data

if-modified-since, cache-control

Waarom REST in plaats van SOAP?

SOAP is uitgegroeid tot een uitgebreide en soms complexe standaard. Voor de meeste toepassingen is deze uitgebreide functionaliteit niet nodig en kan worden volstaan met een eenvoudiger alternatief zoals REST. Veel van de API's en frameworks die SOAP ondersteunen zijn dan ook niet nodig bij REST. Bovendien ligt de netwerk overhead bij SOAP een stuk hoger door het gebruik van envelopes en de wijze van het aanvragen van XML-requests.

Gebruik van REST maakt het ontwikkelwerk dus eenvoudiger en levert daardoor besparingen op gedurende de ontwikkeling.

REST heeft in tegenstelling tot SOAP echter geen eigen beveiliging. Beveiliging van de webservice gebeurt op het niveau van de infrastructuur bijvoorbeeld met SSL, een ACL (Access Control List) of een gebruikersnaam en password combinatie. In de meeste gevallen zal dat voldoen.

REST is niet per definitie de juiste keuze boven SOAP. De uitgebreide functionaliteit en de beveiligingsmogelijkheden van SOAP en het feit dat SOAP een W3C standaard is kan SOAP de betere keuze maken bij specifieke problemen.
Per scenario moeten een afweging worden gemaakt. Criteria zijn onder andere: beschikbare kennis binnen het bedrijf, de technische eisen van derde partijen, de gebruikte programmatuur en programmeeromgeving, beveiligingseisen en voorkeur.

REST in de "echte" wereld

REST is momenteel veel besproken omdat Yahoo heeft gekozen haar services middels REST aan te bieden, in plaats van SOAP, zoals bijvoorbeeld Google heeft gedaan. Als rationeel voor deze keuze stelt Yahoo dat REST een kortere leercurve heeft, makkelijk te implementeren is, toegankelijk is vanuit de meeste moderne programmeertalen en voldoende kracht heeft om aan de eisen van Yahoo te voldoen.

Na het bekijken van de documentatie ziet de implementatie van Yahoo’s webservice er zeer krachtig uit. De meeste functies zijn beschikbaar via HTTP/GET. Dit houdt in dat er een URL wordt opgegeven met daaraan parameters. Deze retourneert op basis van de parameters een XML document met ofwel de gevraagde gegevens ofwel een foutmelding.

Een voorbeeld van een URL met parameters voor het zoeken op de termen “REST Architecture” in alle PDF documenten kan als volgt worden gesteld:

http://api.search.yahoo.com/WebSearchService/V1/webSearch?
 appid=RestDemo&query=REST%20Architecture&format=pdf

Deze URL is zowel vanuit bijvoorbeeld een browser aan te roepen als vanuit programmacode.

Het eerste gedeelte van de XML response van de aanroep is hieronder te zien:

Dit voorbeeld laat de kracht van REST zien; het op een zo simpel mogelijke manier beschikbaar stellen van een applicatie.

Naast Yahoo heeft onder andere ook Amazon hun webservices beschikbaar gesteld via REST. Amazon heeft overigens zowel een REST als een SOAP webservices naast elkaar, dit om te zorgen dat ontwikkelaars de keus hebben om XML of SOAP te gebruiken.

Conclusie

Steeds meer bedrijven stappen over naar webservices en willen dit op een zo simpel en effectief mogelijke manier doen.

Als alternatief voor SOAP lijkt REST een sterke toekomst te hebben. REST is niet zo uitgebreid als SOAP maar biedt afdoende functionaliteit voor de meeste applicaties. De doorlooptijd voor het creëren van een webservice in REST ligt lager dan die van het SOAP equivalent. Ook de leercurve van REST ligt lager dan die van SOAP. De drempel om webservices te ontwikkelen ligt daardoor lager. Bovendien heeft REST zich inmiddels ook bewezen in productie omgevingen.

Relevante Links

 

Over de schrijver
Barre Dijkstra is een Java consultant met 7 jaar industrie ervaring en meer dan 5 jaar Java ervaring. Hij heeft ervaring met architectuur en implementatie van hoge volume J2EE applicaties in gedistribueerde omgevingen.

Waardering:
 
Tags:

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.