geconstateerd, oppervlakte, gebruiksdoel en type ook toestaan op andere parametercombinaties

[fsamwel]

Bijvoorbeeld combinatie met pandIdentificatie:

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "De combinatie van opgegeven parameters is niet toegestaan.",
    "status": 400,
    "detail": "Bad request.",
    "instance": "https://api.bag.acceptatie.kadaster.nl/esd/huidigebevragingen/v1/adresseerbareobjecten?gebruiksdoelen=woonfunctie&geconstateerd=true&type=verblijfsobject&pandIdentificatie=0599100000103376",
    "code": "unsupportedCombi"
}

Besproken met @CathyDingemanse en zij ziet geen reden dit niet toe te staan. Bijvoorbeeld de combinatie pandIdentificatie met gebruiksdoelen is ook logisch gebruik, om alle woningen in een flat te krijgen (en dus de serviceruimtes eruit te filteren).

Ook denk ik dat we zoveel mogelijk ingewikkelde eisen voor de gebruiker, die alleen uit het lezen van de description te halen zijn, moeten voorkomen. Voor minimaal op te geven parameters is dat wellicht onvermijdelijk, maar het verbieden van deze combinatie zou m.i. toch mogelijk moeten zijn.

[strijm]

@CathyDingemanse @fsamwel
Zouden jullie user stories willen maken voor de mogelijke zoek functionaliteiten, zodat we precies weten welke combinaties we moeten ondersteunen?
Deze vraag stond ook in #470.

[CathyDingemanse]

Voor #470 geldt dit iig niet. Wij willen voorlopig geen andere parameters toestaan in combinatie met de vrije contour.

[fsamwel]

Zouden jullie user stories willen maken voor de mogelijke zoek functionaliteiten, zodat we precies weten welke combinaties we moeten ondersteunen?

Ik zie het eigenlijk andersom. Standaard REST API functionaliteit is filteren met parameters, dus dat elke parameter samen met elke andere gebruikt kan worden. Ik snap de eis dat er minimaal een relevante parameter wordt gegeven, anders kan de API gebruikt worden om de hele BAG te downloaden, en dat is nadrukkelijk niet de bedoeling van de API. Dus moet je minimaal een van de parameters nummeraanduidingIdentificatie, pandIdentificatie, pandidentificaties of bbox. Maar dat wil niet zeggen dat het combineren van parameters daarmee ook uitgesloten moet worden. En dus ook niet waarom het aanvullend gebruiken van extra parameters als type en gebruiksdoelen verboden zou moeten zijn.

Ik had het verbieden van combinaties uit de specificaties ook niet geconcludeerd (en had er dus ook nog geen testgevallen voor om dit te testen). Vraag me af of dit voor andere gebruikers wel duidelijk is.

Een voorbeeld van een user Storie is de combinatie pandIdentificatie(s) met gebruiksdoelen. Bijvoorbeeld om alle bewoners van een (of meerdere) pand(en) aan te schrijven (en de serviceruimten en winkels en kantoren in hetzelfde pand niet).

[fsamwel]

In overleg besproken. eerst uitzoeken wat functioneel de wens is en hoe dit opgelost moet worden (in een volgende release).

issue is gevolg van:

• niet duidelijk uitwerken van user story
• verschil in interpretatie user story: hoe strikt exact (alleen) leveren van wat gevraagd is in user story (en beperken wat niet expliciet gevraagd is) versus standaard REST API waarbij parameters filters zijn en gebruikers gegenereerde code direct moeten kunnen gebruiken (zonder toelichtingen en features te moeten lezen en dat te implementeren).