Open rien333 opened 1 month ago
Ik ben het grotendeels met @rien333 eens, maar denk dat we hier niet om het gehele ingevulde natuurlijkpersoon
object hoeven te vragen. Het id voor natuurlijkPersoon zou hier afdoende moeten zijn, aangezien verwerkende software die kan gebruiken om waar nodig de natuurlijke person op te halen met GET /natuurlijkpersonen/{id}
Dit voorkomt complexiteit bij het invullen van alle velden van informatieobject
maar denk dat we hier niet om het gehele ingevulde natuurlijkpersoon object hoeven te vragen.
Eens! Iets anders dan het simpelweg verwijzen naar een ID van een natuurlijk persoon zou inefficient zijn. In die zin is het misschien vooral een kwestie van de documentatie aanpassen?
Lijkt me een goed idee om portefeuillehouder
te modelleren als Natuurlijk Persoon
. Dit zal in de API betekenen dat je met een id
veld kunt verwijzen naar de natuurlijke persoon zodat je die kunt ophalen met de call GET /natuurlijkpersonen/{id}
.
Het
Voorstel
-informatieobject heeft een attribuutportefeuillehouder
. Volgens de documentatie benodigd dit attribuut een character string:Het lijkt mij conceptueel logischer om hier om
natuurlijkPersoon
te vragen, ipv eenCharacterString
. Dit heeft ook een ander mogelijk voordeel, namelijk het kunnen achterhalen van de eventuele rol van de portefeuillehouder binnen de vergadering. Was de portefeuillehouder bijvoorbeeld ook aanwezig tijdens de vergadering? Heeft zij nog ingesproken tijdens de vergadering? Als je de portefeuillehouder definieert als eennatuurlijkPersoon
is dit soort info waarschijnlijk makkelijker te achterhalen.