Noodzaak voor generieke API-strategie m.b.t. geo

[frisopenninga]

REST API's gebruiken generieke webstandaarden, maar aanvullende afspraken kunnen wenselijk zijn. Zo stelt de (concept) API strategie voor het Digitaal Stelsel Omgevingswet bijvoorbeeld dat geo-informatie in GeoJSON-formaat wordt geleverd, maar doet de strategie ook aanvullingen om met RD en ETRS'89 om te kunnen gaan, als aanvulling op het in GeoJSON vereiste WGS'84 coördinaatsysteem om te gaan. Daarnaast worden bijvoorbeeld ook aanvullende eisen m.b.t. taal en documentatie gesteld.

Binnen de set geostandaarden kennen we onder de noemer Nederlandse profielen dergelijke aanscherpingen op internationale standaarden (NL-profielen om WMS en WFS en NL-profielen op metadata van data en services).

De vraag is of het noodzakelijk / wenselijk is om een Nederlands profiel op REST API's op te stellen (en die Nederlands profiel of API-strategie te noemen), waarin voor geo-informatie dergelijke aanvullende eisen worden gesteld die daarmee generiek en uniform zijn voor alle toepassingen binnen de reikwijdte van de Pas toe of leg uit-lijst. Alternatief is om dergelijke aanscherpingen per domein te organiseren en dus niet op nationaal niveau generiek te standaardiseren.

[thijsbrentjens]

Ik kan de behoefte bij organisaties niet goed inschatten hiervoor. Maar zie ook issue #15 .

Wat belangrijk is om te beseffen dat REST niet zo zeer een standaard is, maar eerder een bepaalde aanpak. Wat wel gestandaardiseerd is, is het gebruik van HTTP, maar op een niveau hoger (qua functionaliteit van een API), is er weinig gestandaardiseerd. Misschien nuttig om nog wat hardcode web ontwikkelaars te vragen hoe zij hier tegenaan kijken. Los daarvan: ik denk dat een profiel voor REST API's lastig is / wordt, als je dat een vergelijkbare status als de andere service profielen wilt geven. Een soort praktijkrichtlijn of handreiking kan nog wel, maar dan ben je wel klaar denk ik.

[Naisunev]

Voor rest api's wordt veel "SWAGGER" gebruikt als soort van beschrijving van de API. Ik zie ook bijna geen enkele REST service zich aan de officiele "RESTFUL" service aanpak houden en ben het dus eens dat REST niet echt een standaard maar een losse manier van werken.

Het lijkt mij interessant om bijvoorbeeld SWAGGER uit te breiden met eigenschappen die samenhangen met b.v. JSON-LD om ook dat mee te kunnen nemen.

[wisze]

XML wordt tegenwoordig als lastig en gecompliceerd ervaren en JSON als snel en duidelijk. Of dat terecht is is de vraag, het lijkt meer voort te komen uit het feit dat in de JSON wereld ook uitgegaan wordt van versimpelde informatiemodellen. Maar die ontwikkeling naar JSON is wel een ontwikkeling om rekening mee te houden. Afspraken op nationaal niveau om de basis van gegevensuitwisseling werkbaar te houden lijkt me een een goed idee. Met name het feit dat coordinatensystemen die voor NL gebruikelijk zijn niet worden ondersteund door GeoJSON lijkt me wel een probleem. De waterbeheerders hebben hun gegevens in RD staan, dat wordt natuurlijk ETRS. Converteren naar WGS84 voor uitwisseling is natuurlijk mogelijk maar dat geeft weer andere mogelijke problemen.

[frisopenninga]

REST is een architectuur patroon en geen standaard en vraagt een andere aanpak bij het standaardiseren dan bekende uitwisselstandaarden van OGC of de overheid (StUF, Digikoppeling). Je kan bij het toepassen van het REST architectuur patroon een aantal zaken volledig standaardiseren, voor andere zaken is een best practice of een aantal ontwerp-overwegingen afdoende. Het resultaat van het toepassen is een REST API. Hoe hiermee om te gaan leg je vast in een API strategie. Het is niet een geval van "one size fits all", de API strategie zal dus niet alles in beton gieten maar de gebruiker ervan de vrijheid geven om een voor zijn situatie passende oplossing neer te zetten. Er lijkt behoefte te bestaan aan een generieke API-strategie voor de overheid, waarin zowel op strategisch als technisch niveau een aantal aanbevelingen gedaan kan worden (bijv. met betrekking tot RESTful principes, beveiliging, geo-aspecten en documentatie).

Geonovum zal proberen om alle relevante overheidspartijen te betrekken bij een initiatief om tot een overheidsbrede API strategie te komen.