Kadasterpersonen als aparte API definieren ?

[JohanBoer]

Kadaster-personen bevragen --> Afsplitsen endpoints van BRK-bevragen. Is hier nog steeds behoefte om de specs hiervan in een aparte API te gieten ? Zo ja, doen we dit op zo'n manier dat er geen impact is voor de consumers (lijkt me wel…). --> Bespreken we volgende week als Melvin er weer bij is. Daarna op de lijst om met Kadaster te bespreken.

[JohanBoer]

Inmiddels met Melvin besproken. Hier zijn diverse opties. Vooral nieuwe inzichten ontstaan m.b.t. versionering en granulariteit van API-specs. We moeten een vervolg-afspraak inplannen om te bepalen welker route we hier willen nemen ne hoe we dat met bv. de API-strategie in overeenstemming houden / krijgen. Dit alles om het risico op breaking changes voor consumers te beperken. Vraagstukken:

• Is het major-versienummer in de URL wel zo verstandig.
• We doen nu aan "Lazy"-versioning (op een te hoog niveau).
• Moet versioning niet op resource- of zelfs op endpoint niveau plaats vinden ?
• Maak onderscheid tussen intern beheer van de API-spec en hoe deze specs gepubliceerd worden (Consumer wil geen 20 API's hoeven te configureren. Gebruik naar buiten toe dezelfde Base-URL)
• Voorstel om het deprecated-mechanisme te gebruiken om breaking changes zoveel mogelijk te voorkomen.
• Gebruik van GraphQL inventariseren.

[melsk-r]

Het idee is om hier geen aparte API van te maken maar om de domain.yaml wel op te splitsen in aparte bestanden. @JohanBoer : Onduidelijk is wat de bedoeling is van de inventarisatie van GraphQL.

[JohanBoer]

Gaarne nogmaals bespreken. We hebben de BRK-bevragen API al in kleinere yaml's opgedeeld om het overzicht te bewaren. Ik zie de toegevoegde waarde van het opdelen van de domain.yaml niet als we er geen aparte API van gaan maken. Als deze endpoints onderdeel blijven van deze API gaan ze ook altijd mee bij het ophogen van een versienummer.

[fsamwel]

beter indelen van de yaml: #57