De documentatie voor de ontwerpkeuzes 'Vertaling van relaties' en 'Many-to-many relaties verspreid over API's' dient aangepast te worden...

[EdwinCoster]

...zodat deze in lijn is met de veranderde werkwijze.

De documentatie voor 'Vertaling van relaties' en 'Many-to-many relaties verspreid over API's' is initieel opgesteld toen de relatie tussen zaak en document werd gelegd vanuit document. In issue VNG-Realisatie/gemma-zaken#979 is deze relatie omgedraaid. De documentatie weerspiegelt dit nog niet. Dit moet aangepast worden.

[michielverhoef]

Ik zou dit eigenlijk een bug noemen. Niet om lelijk te willen doen maar als de documentatie iets anders beschrijft dan het gedrag van de RI is dan is dat niet handig. Zoiets moet gerepareerd worden.

[EdwinCoster]

Mede naar aanleiding van VNG-Realisatie/asterix#91 is afgesproken dat many-to-many relaties verspreid over API's gesynchroniseerd worden, zoals beschreven in de ontwerpkeuze.

In het ontwerp van de klantinteractie API's (Klanten API, Contactmomenten API en Verzoeken API) is de keuze gemaakt om de relaties niet te synchroniseren met als uitgangspunt dat een gemeente één instantie van deze API's gaat implementeren. Dit in tegenstelling tot b.v. de Zaken of Documenten API, waar meerdere instanties van te verwachten zijn. Wij zijn tot de conclusie gekomen dat dit uitgangspunt niet houdbaar is. Hierdoor zal de bovengenoemde ontwerpkeuze ook op de relaties van andere ZGW API's met de klantinteractie API's en de klantinteractie API's onderling worden toegepast.

Dit betekent:

• Uitbreiding van de enumeratie voor het attribuut objectType in de resource objectinformatieobject in de Documenten API met de waarde verzoek
• Uitbreiding van de enumeratie voor het attribuut objectType in de resource objectcontactmoment in de Contactmomenten API met de waarde verzoek
• Aanpassen van de naam van de resource klantcontactmoment naar contactmomentklant in de Contactmomenten API
• Aanpassen van de naam van de resource klantverzoek naar verzoekklant in de Verzoeken API
• Toevoegen van een resource objectklant in de Klanten API met contactmoment en verzoek als mogelijke waarden van in de enumeratie voor het attribuut objectType

En leidt tot de volgende user stories:

• Spiegelen van de relatie tussen verzoek en informatieobject in de documenten API VNG-Realisatie/klantinteracties#120;
• Bijwerken van de relaties tussen de klantinteractie API's VNG-Realisatie/klantinteracties#118 .

Verder:

• Documentatie aanpassen (o.a. klanten, contactmomenten, verzoeken, zaken en documenten);
• Daarbij ook controleren dat waar in de API specificaties en documentatie verwezen wordt naar Klantinteracties API we gaan verwijzen naar de juiste klantinteractie API;
• Gegevensmodel aanpassen;
• Zorgen dat toekomstige versies van de API specificatie te benaderen zijn via de documentatie. Via de zaken API op github.io kan ik nu alleen een API-spec benaderen zonder resources zaakcontactmoment en zaakverzoek.