Ter info vooraf: in de ten tijde van publicatie van dit issue actuele concept-API-specs worden bij het registreren van een objectidentificator separate referentielijsten gebruikt voor registers, objecttypen en soortObjectId's.
Hierover stelde ik in een review de volgende vraag:
Vraag over referentielijsten voor objectidentificatoren. Ik had gedacht (maar blijkbaar niet uitgesproken) dat zo'n referentielijst (hoewel het dan stikt genomen niet meer helemaal een lijst is) op iedere regel een een geldige combinatie van register, objecttype en soortObjectId zou omvatten. Maar ik realiseer me nu pas dat we het helemaal niet zo hebben vormgegeven. Zou het niet toch te overwegen zijn alsnog deze weg - die voorkomt dat per ongeluk 'ongeldige combinaties worden geregistreerd van bijvoorbeeld objecttypen met soortenID's die helemaal niet voorkomen in de registers waaraan ze gekoppeld zijn geraakt - te volgen?
Moet een referentielijst voor register dan een een volledige set aan alle mogelijke objecttypen bevatten, en dan per objecttype ook weer een lijst van alle attributen (=soortObjectId)?
Dit lijkt me niet werkbaar. Elke API wijziging (welke dan ook) zou dan theoretisch een wijziging in de referentielijst inhoud betekenen.
Alternatief is dat je de lijst flink limiteert en simpelweg aangeeft dat Partij en Klantcontact de enige objecttypen zijn, en je niet kan verwijzen naar een Interne taak bijvoorbeeld. Maar dit ondermijnt weer een beetje het flexibele karakter van die identificator constructie.
Ik zou het liefst die validatie zien maar ik zie niet direct hoe.
Reactie Johan:
Dit zou absoluut een goede mogelijkheid zijn. Dat betekent dat er maar 1 referentielijst is waar de geldige combinaties in opgenomen zijn. Wat dan wel moeilijker wordt is het zoeken op een dergelijke externe ID. In de huidige opzet kan ik aangeven dat ik op een ID zoek en dat dat een burgerservicenummer is.
In de opzet zoals jij die voorstelt kan je dan wel zoeken op die ID, maar wordt het best complex om aan te geven dat dat een burgerservicenummer is.
Nemen we dit als issue op om binnenkort uit te werken ?
Reactie Ivo:
Hoe zie je die validatie dan voor je?
Ik bedoelde met 'geldige combinatie' niet per se 'gevalideerde combinatie', maar ga ervan uit dat je bij het configureren van een referentielijst iets beter oplet voor je een nieuwe waarde toevoegt dan wanneer je - gechargeerd, want de consumer kan hier natuurlijk ook bij helpen - voor de 23e keer op één dag de juiste combinatie van register, objecttype en soortObjectId bij elkaar puzzelt.
Moet een referentielijst voor register dan een een volledige set aan alle mogelijke objecttypen bevatten, en dan per objecttype ook weer een lijst van alle attributen (=soortObjectId)?
Ik neem juist aan dat je per register alleen de objecttypen opneemt waarnaar je in redelijkheid zou kunnen willen verwijzen. Dat zal een beperkt aantal zijn. Hoe beperkt zal de praktijk moeten uitwijzen. Voor soortObjectId geldt hetzelfde, maar nog sterker; ik kan me bijna niet voorstellen dat er gevallen zijn waar je meer dan twee attribuutsoorten van één objecttype als objectId wil kunnen overnemen.
Ter info vooraf: in de ten tijde van publicatie van dit issue actuele concept-API-specs worden bij het registreren van een objectidentificator separate referentielijsten gebruikt voor
registers,objecttypenensoortObjectId's.Hierover stelde ik in een review de volgende vraag:
Reactie Joeri:
Reactie Johan:
Reactie Ivo:
Acceptatiecriteria
Definition of done