ReST

Syndicate content

Kenmerken van een succesvolle webservice

berry.groenendijk 19 Aug 2010

Een (web)service is pas een service als deze wordt gebruikt en vooral wordt hergebruikt voor andere doeleinden of toepassingen dan waar de service oorspronkelijke voor in het leven is geroepen. Maar, hoe bevorder je nu (her)gebruik van bedrijfsservices?

Een veel gebruikte methode om het gebruik van services te bevorderen is het instellen van ‘governance’. Een comité stelt beleid op ten aanzien van de benodigde services en het gebruik ervan. En daar waar beleid wordt gecreëerd dient deze ook te worden afgedwongen. Eventueel zelfs met repercussies. Een goed comité zorgt ervoor dat het opgestelde beleid breed gedragen wordt binnen een organisatie. Bijvoorbeeld door belanghebbenden uit de organisatie innig te betrekken bij het opstellen van het beleid.

Desondanks blijkt de praktijk weerbarstig en loop je bij de implementatie van services tegen zaken als de volgende aan:

  • SOA webservices, met name W3C webservices, zijn sterk gestandaardiseerd. De standaarden zijn echter complex en ook de op de standaarden gebaseerde software is technisch complex;
  • Services zijn vaak een compromis qua functionaliteit. Er is altijd iemand die teleurgesteld is in wat een service kan. Dit remt hergebruik;
  • Doorontwikkelingen kosten in de praktijk vaak veel tijd. Vanwege de complexiteit van de software, maar mogelijk ook vanwege de regeldruk van de governance zelf;
  • Financiering kan een rol spelen. Bijvoorbeeld: de eigenaar van een service wil niet dat de ontwikkelkosten van een gewenste functionaliteit van een andere afdeling op zijn/haar budget drukt;
  • Versiebeheer van W3C webservices maakt bijvoorbeeld dat afnemers vaak gedwongen hun software moeten aanpassen zonder dat er voor hen een directe noodzaak is of dat er direct voordeel uit te halen is.

Daar waar webservices binnen bedrijven vaak maar moeizaam worden (her)gebruikt zijn services die gekoppeld zijn aan applicaties en diensten op het internet vaak enorm populair. Sterker nog, de webservice vormt soms zelfs de basis van het succes van een internet applicatie. Wat maakt deze webservices zo populair? En wat kunnen eigenaren van webservices binnen bedrijven hiervan leren?

Een goed voorbeeld is Twitter. Twitter heeft een website waarmee je Twitter berichten kan schrijven. Maar, de meeste mensen gebruiken één van de vele Twitter programma’s voor op hun computer of voor op hun mobiele telefoon om Twitter berichten te volgen en te schrijven. Die vele tientallen programma’s kunnen ontstaan omdat Twitter een eenvoudig te gebruiken webservice aanbiedt.

Laten we de Twitter webservice eens zelf gebruiken. De volgende link toont alle Twitter berichten van de gebruiker ‘infoinnovator’ in zogenaamd JSON formaat: Twitter berichten van InfoInnovator. Wat je te zien krijgt is afhankelijk van de browser die je gebruikt, maar als het goed is zie je een lijst van Twitter berichten met nog een hele hoop informatie er omheen.

Waar het mij met dit voorbeeld om gaat is de eenvoud. Een simpele url die je in je browser kan plakken geeft je toegang tot de gestructureerde informatie van een internet dienst. Iedereen kan dit doen. Als afnemer heb ik aan niemand toestemming hoeven te vragen om dit te doen. Ik hoef ook aan niemand verantwoording af te leggen wat ik met de informatie ga doen. Ik kan mijn idee, om bijvoorbeeld een helemaal te gek en hip Twitter programma te maken, heel snel uitproberen. De drempel voor ontwikkelaars maar ook anderen om de Twitter webservice te gebruiken is dus heel erg laag. Dat verklaart de grote hoeveelheid aan Twitter programma’s en andere vormen waarin Twitter wordt gebruikt. Gebruikers kiezen hun favoriete programma en gaan Twitteren dat het een lieve lust is. En het gebruik van het Twitter platform en dus niet zozeer de website zelf, groeit enorm. Twitter is een platform. Een dienst waarop anderen hun diensten weer kunnen bouwen. Een informatie ecosysteem met de dienst Twitter in het middelpunt.

Natuurlijk is niet alle informatie op Twitter zo gemakkelijk toegankelijk. Bepaalde functies zijn beveiligd en alleen toegankelijk na authenticatie. Maar, de basis blijft eenvoud.

Als ik een aantal populaire internet webservices langs loop dan hebben die de volgende kenmerken. De webservice…

  • heeft een voor de gebruiker duidelijk en nuttig doel;
  • is laagdrempelig, eenvoudig en simpel in gebruik;
  • kent een (zeer) liberaal beleid ten aanzien van het gebruik van de webservice;
  • kent een levendige en actieve community van gebruikers die elkaar informeren en helpen en waarbij de webservice eigenaar actief participeert in die community;
  • biedt continu nieuwe, innovatieve en of verbeterde mogelijkheden;
  • heeft zo min mogelijk beveiliging daar waar het kan en een zo streng mogelijke beveiliging daar waar het moet;
  • is technisch eenvoudig, waarbij de techniek heel nauw aansluit bij reeds bestaande en algemeen geaccepteerde technieken (REST);
  • is flexibel in het ondersteunen van meerdere formaten waarin je de informatie kan opvragen;
  • kent een informatiestructuur die losjes en iteratief tot stand is gekomen;
  • heeft uitstekende documentatie die de service beschrijft met praktisch toepasbare voorbeelden;
  • kent een duidelijk (informatie)beleid ten aanzien van nieuwe versies van de webservice met ruime overgangsperioden;
  • is financieel vaak omzet gedreven in tegenstelling tot interne bedrijfsservices die vaak kosten gedreven zijn. Dit verschil is ook van invloed op hoe je tegen doorontwikkelingen van de webservices aankijkt.

Mijn persoonlijke mening is dat het succes van internet webservices uiteindelijk zal overslaan op het bedrijfsleven en de overheid, waarbij de goede dingen van W3C enterprise webservices elkaar zullen ontmoeten in de goede dingen van de internet REST webservices.

Bedrijven, gemeenten en instellingen hebben zo hun eigen dynamiek. Het zijn niet allemaal hippe internetbedrijven. Per bedrijf zal je moeten kijken wat het beste bij je past. Of juist sterk gestandaardiseerde systemen met stevige governance of juist meer laagdrempelige, eenvoudig te gebruiken systemen met een meer liberaal gebruiksbeleid of wellicht een mix van beide. Kies, maar kies weloverwogen.

Berry Groenendijk is informatie architect bij Caerleon.

 

Hypermedia en informatie architectuur

berry.groenendijk 06 Apr 2009
Het internet, het bekendste voorbeeld van een hypermedium, heeft tot een enorme groei van electronisch beschikbare informatie geleid. Met behulp van hyperlinks worden verschillende informatieblokken aan elkaar gekoppeld waardoor een web van informatie ontstaat. Op het internet worden al deze hyperlinks gemaakt zónder dat er bijvoorbeeld een centrale faciliteit is die garandeert dat alle hyperlinks ook geldig zijn. Er niets dat garandeert dat een hyperlink ook daadwerkelijk aankomt. Dit lijkt een enorme tekortkoming, maar het heeft er in werkelijkheid mede toe geleid dat internet pagina's (HTML documenten) zeer gemakkelijk te maken, te publiceren en te (her)gebruiken zijn. Het publiceren van informatie op internet is dusdanig laag drempelig geworden dat bijna letterlijk iedereen informatie kan delen met letterlijk de hele wereld.

Bovenstaande roept bij mij als informatie architect de volgende vragen op. Zijn deze uitgangspunten van het internet ook toe te passen op bedrijfsapplicaties? Welke voor- of nadelen levert dit op voor bedrijven en met name voor medewerkers binnen een bedrijf? En wat betekent dit voor het werk van de informatie architect?

Een architectuurstijl die aan populariteit wint is ReST (Representation State Transfer). ReST neemt de eigenschappen het hypermedium internet als uitgangspunt. Roy T. Fielding heeft deze architectuurstijl beschreven in zijn dissertatie. In een softwaresysteem gebouwd volgens ReST uitgangspunten vormt de locatie, een URL, van een informatie-eenheid (een "resource") het uitgangspunt. Voor het manipuleren van alle informatie-eenheden staan slechts 4 (Engelstalige) acties ter beschikking: get, post, put en delete. Met behulp van hyperlinks worden alle informatie-eenheden aan elkaar gekoppeld. En ook nu geldt dat niets of niemand garandeert dat een hyperlink ook daadwerkelijk aankomt.

Laten we als voorbeeld alle medewerkers van het bedrijf MijnBedrijf in een ReST softwaresysteem zetten:

De actie GET op de resource http://mijnbedrijf.nl/medewerkers/ toont een lijst van alle medewerkers. Iedere medewerker in de lijst heeft een hyperlink waarmee we detailinformatie van de medewerker kunnen opvragen. Met de actie POST op dezelfde resource voegen we een nieuwe medewerker toe.

De actie GET op de resource http://mijnbedrijf.nl/medewerkers/janjansen/ toont de detailinformatie van de medewerker Jan Jansen. Bijv. een telefoonnummer, een geboortedatum, een foto, etc. Maar, bijv. ook hyperlink naar de afdeling waar de medewerker werkt (bijvoorbeeld: http://mijnbedrijf.nl/afdelingen/inkoop/). Met de actie PUT kunnen we detailgegevens van deze medewerker wijzigen. Met de actie DELETE verwijderen we de medewerker uit het systeem. Stel dat Piet Pietersen helemaal geen medewerker is van MijnBedrijf, dan levert de actie GET op de resource http://mijnbedrijf.nl/medewerkers/pietpietersen/ simpelweg een foutmelding op. De foutmelding geeft aan dat deze resource niet bestaat en dat deze medewerker dus onbekend is binnen MijnBedrijf.

De actie GET op de resource http://mijnbedrijf.nl/afdelingen/ toont alle afdelingen binnen een bedrijf. De lijst bevat ook hyperlinks naar iedere individuele afdeling. Met de actie POST kan een nieuwe afdeling aangemaakt worden.

De actie GET op de resource http://mijnbedrijf.nl/afdelingen/inkoop/ toont de detailinformatie van de afdeling inkoop, zoals een hyperlink naar de manager van de afdeling inkoop. Met de actie PUT kunnen we detailinformatie van de afdeling wijzigen, zoals bijv. de naam van de afdeling. Met de actie DELETE kunnen we afdeling in zijn geheel verwijderen.

De actie GET op de resource http://mijnbedrijf.nl/afdelingen/inkoop/medewerkers/ toont een lijst van hyperlinks naar alle medewerkers van de afdeling inkoop. Voorbeeld van een hyperlink die in de lijst getoond wordt: http://mijnbedrijf.nl/medewerkers/janjansen/.

De voordelen van een systeem gebouwd volgens ReST uitgangspunten is dat het resources kent die heel dicht liggen tegen het informatiemodel van het bedrijf. De urls van de resources zullen voor de medewerkers van het bedrijf dan ook heel natuurlijk overkomen. De beperkte set van acties zorgt er voor dat je gemakkelijk tegen een ReST systeem aan kan automatiseren. Hierbij helpt ook dat ReST verschillende representaties (bijvoorbeeld HTML, XML, JSON, etc.) toestaat van één en dezelfde resource. Een ReST systeem kan dus tegelijkertijd gebruikt worden door mensen maar ook gebruikt worden om bijvoorbeeld integraties met andere bedrijfssystemen te realiseren.

De nadelen van een softwaresysteem gebaseerd op ReST uitgangspunten is de nu nog relatieve onbekendheid. Zeker bij bedrijfsapplicaties. Steeds meer cloud computing diensten op internet, zoals aangeboden door bijv. Amazon en Google, prefereren het aanbieden van een ReST interface op hun diensten in plaats van een interface gebaseerd op een service geörienteerde webservice (SOA). Mede hierdoor zal ook steeds vaker in (standaard) producten ReST interfaces te vinden zijn. 

Voor de informatie architect betekent ReST een nieuwe cq. een andere manier om een informatiemodel uit te werken in een werkend software systeem. ReST legt de focus op het definiëren van informatie-eenheden en op het onderkennen van relaties tussen deze informatie-eenheden. ReST sluit daarmee, naar mijn mening, nauw aan op de kracht van een informatie architect: het maken van een blauwdruk van informatie binnen een kennisdomein.

Berry Groenendijk is informatie architect bij Caerleon.