Uitfaseren vijftal REST API’s per 1 augustus aanstaande

PDOK dataplatform is voornemens om de volgende REST API’s per 1 augustus uit te faseren omdat we zien dat deze REST API’s al langere tijd niet meer actief gebruikt worden. Let op, deze uitfasering betreft alleen de REST API’s die via het dataplatform geleverd worden, de geo webservices voor deze dataset worden niet aangepast.

Wij horen het graag indien één van de onderstaande API’s toch gebruikt wordt en zullen dan met de gebruiker afstemmen of en hoe wij zijn use case het beste kunnen ondersteunen.

2 likes

Ik ben wel benieuwd wat de reden is om uit te faseren. Gaat het om beschikbaarheid van een databron (via een bepaalde ontsluiting) of om de mate van gebruik? Ik kan niet in jullie keuken kijken, maar het lijkt me dat als je eenmaal alles technisch hebt ingericht er weinig onderhoud aan zo’n REST API is, noch dat deze veel resources neemt? Wat is er op tegen deze al ingerichte API te laten staan en te zorgen dat ze goed vindbaar zijn? Dan zijn ze beschikbaar op het moment dat de behoefte tot gebruik ontstaat. Op zich kan ik me namelijk voorstellen dat met de groei van het aantal databronnen sommige (misschien zelfs wel de meeste) databronnen/publicate-vormen een miniem gebruik zullen hebben in de tijd met wellicht af en toe een piek en dat slechts enkele databronnen een veel groter volume aan continu gebruik zullen hebben. Dit zal wellicht ook al zichtbaar zijn in het gebruik van de geo webservices? Ik zou dan eenzelfde beleid voor de REST API’s aanhouden.

Goede vraag, er zijn twee belangrijke redenen:

  • de datasets die achter deze API’s zitten worden niet actief bijgewerkt op dit moment, wat inhoudt dat we wat ons betreft niet de dienstverlening aanbieden die we aan willen bieden.
  • deze API’s zijn ontstaan als prototype ongeveer 2 jaar geleden en zijn daarna niet verder meegegaan in de ontwikkeling van het PDOK dataplatform. De ontwikkeling van het dataplatform is wel heel hard doorgegaan waardoor deze API’s op inmiddels een verouderde versie van onze software stack draaien en daarom niet makkelijk te migreren zijn.

In combinatie met het feit dat deze API’s niet gebruikt worden, maar we wel kosten moeten maken om ze te migreren (zowel de data als de API’s zelf) maakt dat we nu overwegen om ze nu uit te faseren. Het kan daarbij altijd zo zijn dat we deze API’s in de toekomst opnieuw gaan realiseren zodra er vraag naar is.

1 like

Hallo @jasperroes,
Dank voor de toelichting. Die maakt duidelijk dat jullie in dit geval een logische route volgen.
Maar meer algemeen hoop ik dat het principe van beschikbaarheid boven gebruik gaat.

Hallo @klas2iop, in principe zitten we op de lijn dat we een API zodra deze beschikbaar is gekomen onder versiebeheer plaatsen. Dat houdt in dat we per API regelmatig zullen kijken hoe deze gebruikt wordt, of er gebruikerswensen zijn die we mee kunnen nemen in een nieuwe versie van de API en dat we ook kijken hoe een API gebruikt wordt. Met onze nieuwe architectuur en manier van API’s leveren is het niet veel moeite om een API aan te blijven bieden, ook bij een laag gebruik. Belangrijkste daarbij in een eventuele afweging zal zijn of de content beschikbaar is en blijft (en ook up-to-date gehouden kan worden), als dat zo is verwacht ik niet dat we heel snel een API zullen uitfaseren.

2 likes

Gezien het feit dat er geen verdere reacties zijn gekomen op het uitfaseren van de 5 bovengenoemde API’s gaan we deze per 1 augustus definitief uitfaseren.

Sic transit Mossel- en Oesterhabitats… :cry:

5 likes

Het is niet 1 augustus maar 2 augustus geworden, maar de 5 APIs zijn nu definitief uit de lucht.