Comments (17)
Is het niet zo dat dit een kwestie van applicatie-inrichting is ? Ik neem aan dat er een API komt die binnengemeentelijk zoekt en een andere API die buitengemeentelijk zoekt. Deze API's kunnen qua werking wel 100% hetzelfde zijn, maar hebben verschillende endpoints (want verschillende bronnen). Afhankelijk van de keuze zal dan dus een andere API aangeroepen worden.
Volgens mij lossen we dit niet in de API-specificatie op.
from haal-centraal-brp-bevragen.
Nu nog wel (lokale BRP met gemeentelijke ingezetenen), maar straks hopelijk niet meer.... Willen we de specificatie afhankelijk maken van de huidige implementatie? Of willen we de API specificatie opstellen voor de gewenste situatie? Als de API straks binnengemeentelijk wordt gebruikt heb ik liever geen breaking changes wanneer van bron wordt gewisseld.
from haal-centraal-brp-bevragen.
Ik denk dat we elkaar niet goed begrijpen, want als ik jouw toelichting lees, dan begrijp ik daaruit dat op applicatie-niveau de keuze gemaakt wordt om binnengemeentelijk of buitengemeentelijk te zoeken. Voor nu zouden dat nog 2 verschillende endpoints zijn, maar technisch wel exact dezelfde API's. Dat betekent dat als er (op termijn) 1 landelijke bron komt dat dat geen breaking change op de API oplevert, maar alleen dat zowel binnengemeentelijke als buitengemeentelijke personen op dezelfde endpoint te vinden zijn. Ik denk dat ik dan vooral de gewenste situatie voor oog heb, maar volgens mij is die in de huidige implementatie ook toe te passen. Vrijdag graag bespreken om te checken of we elkaar goed begrijpen...
from haal-centraal-brp-bevragen.
Opnemen query parameter gemeenteVanInschrijving bij het zoeken op geslachtsnaam. ook voor andere zpekpaden moet onderzocht worden of deze parameter toegevoegd moet worden.
from haal-centraal-brp-bevragen.
alternatieve oplossing, met boolean parameter. Cathy werkt dit uit
from haal-centraal-brp-bevragen.
Probleemschets ter bespreking op 12 oktober:
Bij veel zoekopdrachten van gemeenten wordt op dit moment impliciet naar personen gezocht met de parameter "gemeente van inschrijving". Gemeenten zoeken immers in twee registraties: de lokale kopie van eigen ingezetenen (90% van alle vragen), en de GBA-V als men op zoek is naar personen met een verblijfplaats buiten de gemeente.
Bij het opstellen van de specs voor de RSGB bevragingen vs.1 standaard was het zoeken in 1 landelijke registratie geen uitgangspunt. Dit is echter wel van invloed op:
- beperking van het aantal te retourneren personen
- relevantie van het zoekresultaat voor de consumer
- belasting van de provider
De zoekvragen zoals gespecificeerd in RSGB bevragingen waarvoor het niet veel uitmaakt of in 1 of 2 registraties wordt gezocht zijn:
- raadpleeg op bsn
- zoeken op postcode en huisnummer
- zoeken op nummeraanduidingidentificatie
Zoekvragen waarvoor het waarschijnlijk wel uitmaakt of in 1 of 2 registraties wordt gezocht zijn:
- zoeken op geslachtsnaam in combinatie met geboortedatum of voornamen of geboorteplaats, (evt. aangevuld met voorvoegsel geslachtsnaam en geslacht).
De zoekvraag waarvoor het absoluut uitmaakt:
- zoek op geslachtsnaam (minimaal 2 karakters en wildcards toegestaan)
Wat doen we er aan?
Oplossing 1:
- Zoeken op geslachtsnaam alleen ondersteunen icm gemeente van inschrijving.
- In documentatie adviseren de gemeente van inschrijving (standaard) mee te geven bij binnengemeentelijk zoeken.
Oplossing 2:
- een boolean waarmee de afnemer expliciet aangeeft binnen- of buitengemeentelijk te willen zoeken
- zoeken op geslachtsnaam alleen ondersteunen wanneer men binnengemeentelijk zoekt.
In feite is deze boolean hetzelfde als het opnemen van de extra zoekparameter "gemeente van inschrijving" voor alle zoekvragen.
Overwegingen:
- het opgeven van de boolean heeft geen toegevoegde waarde (kan zelfs contraproductief) zijn bij de
zoekpaden:- raadpleeg op bsn
- zoeken op postcode en huisnummer
- zoeken op nummeraanduidingidentificatie
- De boolean binnengemeentelijk kan alleen verplicht worden gesteld icm zoeken op geslachtsnaam,
waarmee hetzelfde resultaat wordt bereikt als met optie 1. - Wat is het meest eenduidig en eenvoudig voor de gebruiker, verplichte zoekparametercombies of
combie parameter met boolean?
Andere overwegingen?
from haal-centraal-brp-bevragen.
ik zou zo dicht mogelijk bij de resource blijven, dus heeft het mijn voorkeur zoveel mogelijk query parameters te gebruiken die ook attributen zijn in de resource. Dan is de werking van de API direct en intuïtief duidelijk.
from haal-centraal-brp-bevragen.
Ik heb nu oplossing 1 (de gemeentevaninschrijving opgenomen als parameter) in de Openapi specificatie opgenomen. De beschrijving welke combinaties van parameters toegestaan zijn moet nog opgenomen worden. De provider zal hier op moeten controleren.
from haal-centraal-brp-bevragen.
Zoeken op geslachtsnaam alleen ondersteunen icm gemeente van inschrijving.
@CathyDingemanse bedoel je dit letterlijk zo? Dus dat bij zoeken op geslachtsnaam de parameter gemeentevaninschrijving verplicht is? (is nu nog niet in de beschrijvingen van de api opgenomen)
Is zoeken met gemeentevaninschrijving=0000 toegestaan?
Hoe interpreteren we de waarde 0000 bij gemeentevaninschrijving? Zoeken we dan een persoon waarvan de gemeentevaninschrijving onbekend is in de registratie (kan dat?) of zoeken we dan een persoon waarvan gemeentevaninschrijving onbekend is voor de client? Dus in willekeurige gemeente (dus zoeken met 0000 is equivalent aan zoeken zonder deze parameter)?
@JohanBoer beschrijving "standaardwaarde is 0000 indien onbekend" bij gemeentevaninschrijving is m.i. niet duidelijk genoeg voor een client.
from haal-centraal-brp-bevragen.
Zoeken op geslachtsnaam alleen ondersteunen icm gemeente van inschrijving.
@CathyDingemanse bedoel je dit letterlijk zo? Dus dat bij zoeken op geslachtsnaam de parameter gemeentevaninschrijving verplicht is? (is nu nog niet in de beschrijvingen van de api opgenomen)
Ja dat bedoel ik letterlijk zo
Is zoeken met gemeentevaninschrijving=0000 toegestaan?
Nee, dat is niet toegestaan, indien 0000 geen geldige gemeente van inschrijving is.
Hoe interpreteren we de waarde 0000 bij gemeentevaninschrijving? Zoeken we dan een persoon waarvan de gemeentevaninschrijving onbekend is in de registratie (kan dat?)
of zoeken we dan een persoon waarvan gemeentevaninschrijving onbekend is voor de client? Dus in willekeurige gemeente (dus zoeken met 0000 is equivalent aan zoeken zonder deze parameter)?
Nee, dat zou niet moeten kunnen.
@JohanBoer beschrijving "standaardwaarde is 0000 indien onbekend" bij gemeentevaninschrijving is m.i. niet duidelijk genoeg voor een client.
from haal-centraal-brp-bevragen.
@CathyDingemanse bedoel je dit letterlijk zo? Dus dat bij zoeken op geslachtsnaam de parameter gemeentevaninschrijving verplicht is? (is nu nog niet in de beschrijvingen van de api opgenomen)
Ja dat bedoel ik letterlijk zo
Dus:
Scenario: Bij zoeken op geslachtsnaam zijn geslachtsnaam en gemeentevaninschrijving verplicht en zijn de overige parameters optioneel
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&gemeentevaninschrijving=0014
DAN levert dit zoekresultaten
# verplicht attribuut gemeentevaninschrijving ontbreekt
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen
DAN levert dit een foutmelding
# verplicht attribuut geslachtsnaam ontbreekt
ALS ingeschreven personen gezocht worden met ?gemeentevaninschrijving=0014&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
# verplicht attribuut geslachtsnaam is leeg/heeft geen waarde
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=&gemeentevaninschrijving=0014&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
# verplicht attribuut gemeentevaninschrijving ontbreekt
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
# verplicht attribuut gemeentevaninschrijving is leeg/heeft geen waarde
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&gemeentevaninschrijving=&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
from haal-centraal-brp-bevragen.
Helemaal goed, met uitzondering van:
- verplicht attribuut gemeentevaninschrijving ontbreekt
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding - verplicht attribuut gemeentevaninschrijving is leeg/heeft geen waarde
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&gemeentevaninschrijving=&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
Deze voldoen nl. wel aan het criterium geboortedatum icm geslachtsnaam.
from haal-centraal-brp-bevragen.
ah, dus je bedoeld dat wanneer je zoekt met alleen geslachtsnaam, zonder geboortedatum, dan is gemeentevaninschrijving verplicht. en wanneer gezocht wordt op geslachtsnaam in combinatie mét geboortedatum, is gemeentevaninschrijving niet verplicht.
mag ik dit ook zo interpreteren dat bij combinatie geslachtsnaam met voornamen en tussenvoegsel ook gemeentevaninschrijving verplicht is?
Dus dit:
Scenario: Bij zoeken op geslachtsnaam zijn geslachtsnaam en gemeentevaninschrijving of geboortedatum verplicht en zijn de overige parameters optioneel
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&gemeentevaninschrijving=0014
DAN levert dit zoekresultaten
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&geboortedatum=1975-01-01
DAN levert dit zoekresultaten
# verplichte attributen gemeentevaninschrijving én geboortedatum ontbreken
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen
DAN levert dit een foutmelding
# verplicht attribuut geslachtsnaam ontbreekt
ALS ingeschreven personen gezocht worden met ?gemeentevaninschrijving=0014&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
# verplicht attribuut geslachtsnaam is leeg/heeft geen waarde
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=&gemeentevaninschrijving=0014&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
# verplicht attribuut gemeentevaninschrijving ontbreekt
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&geboortedatum=1975-01-01&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
# verplicht attribuut gemeentevaninschrijving is leeg/heeft geen waarde en geboortedatum ontbreekt
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&gemeentevaninschrijving=&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
# verplicht attribuut geboortedatum is leeg/heeft geen waarde en gemeentevaninschrijving ontbreekt
ALS ingeschreven personen gezocht worden met ?geslachtsnaam=groen&geboortedatum=&voornamen=Frank&voorvoegselGeslachtsnaam=van&geslachtsaanduiding=M&geboorteplaats=Sas%20van%20Gent
DAN levert dit een foutmelding
from haal-centraal-brp-bevragen.
Super!
from haal-centraal-brp-bevragen.
Bij GemeenteVan Inschrijving is inmiddels in de beschrijving van de query-parameter opgenomen dat deze geen 0000 mag bevatten en in de uitleg over de combinaties van query-parameters is benadrukt dat binnen een combinatie van parameters alle genoemde parameters van die combinatie verplicht zijn.
from haal-centraal-brp-bevragen.
Combinatie zoeken op geslachtsnaam + gemeentevaninschrijving zit nog niet in feature parametercombinaties
from haal-centraal-brp-bevragen.
feature toegevoegd, dus issue kan gesloten worden
from haal-centraal-brp-bevragen.
Related Issues (20)
- description van gemeente van inschrijving op de Persoon aanpassen
- Als PO wil ik het afkorten van voornamen in voorletters bij de afleiding van de aanschrijfwijze in de adressering feature kunnen terugvinden
- Hoe moeten afnemers omgaan met BSN wijzigingen, als we de email (of eventueel het ftp bericht) behandelen als notificatie voor een bepaalde BSN, hoe kunnen we dan zien dat het om een BSN update gaat en hoe kunnen we dan het nieuwe BSN achterhalen? HOT 1
- Als PO wil ik dat het functie-adres wordt toegevoegd aan het gezagPersoonBeperkt
- Als PO wil ik dat de Gezagsmodule rechtstreeks de BRP-V raadpleegt HOT 1
- Als PO wil ik dat de Gezagsmodule met meer dan 1 BSN tegelijk kan worden bevraagd
- Als PO wil ik dat de performance van de gezagsbepaling aan de bestaande eisen voor de Personen API voldoet en een verklaring levert waarom gezag niet bepaald kan worden HOT 2
- Als PO wil ik een nieuwe developer portal voor de afnemers van de BRP API
- Als medewerker van een ziekenhuis wil ik dat voor kinderen die buiten een huwelijk geboren zijn bepaald wordt wie de moeder is
- POC integratie Gezagsmodule in multi container Pod met BRP Personen en A&P microservices HOT 1
- Als medewerker Klant Contact Centrum wil ik een burger aan de telefoon opzoeken met postcode+huisnummer, aangevuld met geboortedatum HOT 2
- De example voor gezag in de redoc OAS spec is niet geimplementeerd HOT 1
- Depricated gegevens uit de fileds tool verwijderen
- Als PO van de NL EU wallet wil ik de voornamen van een persoon kunnen opvragen
- Als PO wil ik dat de example consistent en duidelijk is voor de klant HOT 1
- Als PO wil ik dat de implementatie en documentatie van de Open API spec beter van elkaar kan worden gescheiden.
- Personen API v2.3 zoeken met pc/hn uitbreiden met geboortedatum
- Leveren verblijfplaats land wanneer dat Nederland is HOT 1
- Verbeteren teksten uitleg gezag niet te bepalen
- Als PO wil ik toelichting bij gezag niet te bepalen aanhouden HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from haal-centraal-brp-bevragen.