Documenten API: bij het aanmaken van een ObjectInformatieObject kan ik nog geen Verzoek aangeven als objectType

[michielverhoef]

Bug

Dit zou inmiddels wel moeten kunnen kunnen volgens VNG-Realisatie/klantinteracties#46 maar in de API spec staat deze waarde nog niet beschreven in de enumeratie van objectType.

Tenminste, in de standaard en de API specs in de RI kan ik dit niet terugvinden.

http://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/VNG-Realisatie/gemma-zaken/master/api-specificatie/drc/1.0.x/openapi.yaml#operation/objectinformatieobject_create

http://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/VNG-Realisatie/gemma-documentregistratiecomponent/develop/src/openapi.yaml#operation/objectinformatieobject_create

http://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/VNG-Realisatie/gemma-zaken/master/api-specificatie/drc/1.1.x/openapi.yaml#operation/objectinformatieobject_create

Als dit al wel doorgevoerd is moet de documentatie bijgewerkt worden.

[hdksi]

Vraag: is dit een omissie of juist 'by design'?

[Hugo-ter-Doest]

De vraag is of de relatie enkele richting is van Verzoek naar InformatieObject. Ontwerpbeslissing lijkt te ontbreken.

[HenriKorver]

Mijn aanname is dat er maar één Verzoekenregistratie per gemeente zal (moeten) zijn, dit in tegenstelling tot Zakenregistraties waarvan gemeenten er soms meerdere hebben. In dat geval kun je via de Verzoeken API altijd achterhalen bij welk verzoek een document hoort. Dus het is dan niet nodig om ook bij de Documentenregistratie de relatie naar het verzoek bij te houden door middel van synchronisatie.

[hdksi]

Dit is een interessant architectuurvraagstuk. Kunnen we dit aannemen? In welke mate beperkt dit implementerende partijen die toch met meerdere verzoekenregisters willen (of moeten werken)? Wat 'kost' het om daarop wel voorbereid te zijn?

Met andere woorden: welke argumenten zijn er voor of tegen het standaard hanteren van één- of tweerichtingsrelaties?