In het bijgevoegde artikel "REST toegepast op StUF" (zie bijlage) wordt een voorstel gedaan om StUF geschikt te maken voor REST. De notitie bevat een aantal RFC-voorstellen die nog later expliciet ingediend zullen worden op dit forum. Bovendien wordt in de notitie voorgesteld om een aangepaste versie van een oude RFC weer (gedeeltelijk) in "ere" te herstellen, te weten RFC0129.
di, 11-10-2016 - 17.19u
#1
Geschikt maken van StUF voor REST-architecturen
"REST toegepast op StUF" suggereert dat een REST koppelvlak alleen het toepassen van een ander formaat is voor
hetzelfde berichtenverkeer. REST is echter een heel andere architectuurstijl en heeft een andere toepassingsgebied.
Nieuwe (mobiele) applicaties kunnen vaak goed ondersteund worden met een REST/Json-gebaseerd koppelvlak. Dit kan goed
naast het gebruik van de bestaande XML/Soap interfaces bestaan omdat de nieuwe afnemer applicaties niet in dezelfde
entiteiten geintereseerd zijn, maar meer in geaggregeerde, platgeslagen gegevens en vaak ook in combinaties van gestructureerde en
ongestructureerde gegevens uit meerdere bronnen. Zie de bijgevoegde afbeelding voor de plaats van de verschillende koppelvlakken.
In de notitie worden een aantal zaken geintroduceerd die op zijn minst overbodig zijn binnen een REST architectuur:
- De functie 'lijst' kan al worden afgeleid uit de resource uri(template). Maak anders gebruik van content-type of andere headers.
- De functie 'relatie-entiteit' is geredeneerd vanuit het datamodel. In REST architecturen is het gewenst om te werken met 'consumer-driven contracts'. In het voorbeeld zal het voor de afnemer helemaal niet relevant zijn dat de appointment is gemodelleerd als een relatie-entiteit.
Het voorbeeld apointmentRequest van Martin Fowler is niet zo sterk. Ik zou het appointmentRequenst zelf terugsturen met in de locationheader ofwel een link naar de aangemaakte appointment (als de http-status is 201), of een link naar de plaats waar je de status van het request kan opvragen (bij een 202-response).
Dit toont ook wel aan dat de hele werkwijze bij REST heel anders is, dan bij traditioneel StUF berichtenverkeer.
Dat wil niet zeggen dat er geen afspraken gemaakt kunnen worden over standaardisering, maar ik zou dat niet 1-op-1 willen koppelen aan bestaande StUF berichten.
In ieder geval over het gebruik van linkrelations zouden duidelijke afspraken gemaakt moeten worden. Op dit moment zijn er verschillende varianten in omloop (er zijn varianten die veel expressiever zijn dan de in de notitie gebruikte).
N.B. Dit zijn een aantal artikelen waarvan ik vind dat ze goed aangeven wat REST betekent:
REST API design - resource modeling
Evolving distributed systems en The benefits of hypermedia APIs
Entities aren't resources, resources aren't representations
Bijlage
Nog een kleine aanvulling n.a.v. StUF expertgroep 19 oktober: Deze site geeft een overzicht van een aantal van de gangbare werkwijzes rond linkrelaties/hypermedia-formats:
https://sookocheff.com/post/api/on-choosing-a-hypermedia-format/
Ik ben even benieuwd naar de laatste status omtrent het geschikt maken van StUF voor REST architecturen. Er is op dit moment vanuit het Forum Standaardisatie een expertgroep die bezig om REST Open API Specification (OAS 3.0) op de pas-toe-of-leg-uit lijst te krijgen. In deze expert groep wordt wel HL7 FHIR vanuit de zorg sector steeds als voorbeeld genomen, maar mis ik eigenlijk de relatie mbt het gemeentelijke domein rondom de StUF berichten. Is iemand bekend met dit traject en in hoeverre wordt StUF hierin ook betrokken?