Spectral is een open source linter waarmee je regels voor API-documentatie vastlegt in een ruleset en die vervolgens automatisch controleert. Die tool ligt onder vuur. Er staan honderden issues en pull requests open, de VS Code-plugin loopt achter, en half juli kwam daar een supply chain-incident in een van de dependencies bovenop. Dat laatste was voor veel mensen de druppel. Omdat onze eigen tooling op Spectral draait en de API Design Rules ermee beschreven zijn, uitten veel mensen daar terecht hun zorgen over. Ons antwoord: we slopen Spectral er niet halsoverkop uit, want er zit juist beweging in de richting die we toch al op wilden. Hieronder leggen we uit waar we staan en wat we doen.

In gesprekken over API's binnen de overheid komt GraphQL regelmatig voorbij. Sommige organisaties experimenteren ermee, grote internationale platformen zoals GitHub en Shopify bieden er publieke API's mee aan, en tegelijkertijd is het binnen de Nederlandse overheid nog nauwelijks zichtbaar: het API-register op deze site is bewust REST-only, en de REST API Design Rules (ADR) zijn, de naam zegt het al, geschreven voor REST.

Reden genoeg om GraphQL eens grondig onder de loep te nemen. In een serie van vier blogposts verkennen we wat GraphQL is, wat het oplost, welke uitdagingen het met zich meebrengt en, als kernvraag, wanneer je het wel en wanneer je het beter niet kunt gebruiken.

Binnen de publieke sector groeit de behoefte aan goed gedocumenteerde, interoperabele en toekomstbestendige API's. De REST API Design Rules (ADR) vormen daarbij een belangrijk referentiekader: ze stimuleren eenvoud, voorspelbaarheid en brede toepasbaarheid door gebruik te maken van open standaarden.

Regelmatig komt de vraag voorbij of OData, een specificatie ontwikkeld binnen het Microsoft-ecosysteem, een slimme keuze kan zijn voor publieke API's. In dit artikel analyseren we de voor- en nadelen van OData, met nadruk op eenvoud, interoperabiliteit en vendor-neutraliteit. Ook bekijken we hoe OData zich verhoudt tot de ADR, en op welke vlakken deze conflicteren.

EMREX is een gestandaardiseerd Europees netwerk, ontworpen om de uitwisseling van studieresultaten (diploma's, certificaten, etc.) tussen onderwijsinstellingen en andere belanghebbende organisaties te vergemakkelijken. Het speelt een belangrijke rol in het internationale onderwijslandschap, omdat het studenten en onderwijsinstellingen in staat stelt om studiegegevens snel, veilig en betrouwbaar te delen.

Als je gaat starten met het ontwikkelen van een API zijn er verschillende manieren om dit aan te pakken. In de praktijk zie je grofweg 2 verschillende methoden: "design-first" en "code-first". In dit artikelen leggen we uit wat de verschillen zijn en waarom de "design-first" aanpak wat ons betreft de voorkeur heeft.

Iedere gebruikerstoepassing heeft een specifieke informatiebehoefte, die in veel gevallen meerdere databronnen overstijgt. Toepassingen moeten in dat geval in staat zijn om op een betrouwbare manier gegevens van meerdere bronnen te raadplegen en waar nodig met elkaar te combineren tot het gewenste informatieproduct in de ‘taal’ van de gebruiker.

Al sinds 2020 staan de REST API Design Rules op de pas-toe-of-leg-uit lijst van het Forum Standaardisatie, wat maakt dat deze verplicht zijn gesteld voor alle Nederlandse overheidsorganisaties. Deze design rules beschrijven een set regels waar een REST API aan zou moeten voldoen, met als doel meer uniformiteit aan te brengen in het informatielandschap van de overheid. In dit artikel geven we een aantal argumenten waarom API design rules zo waardevol zijn.