Impediment DRC 1.1 Bestandsdelen request t.o.v. DRC 1.0.1

[shazada]

Impediment

Samen met WeAReFrank zijn we aan het kijken of we tijdelijk een vertaling kunnen maken tussen de 1.1 API naar 1.0.1 en we kunnen realistisch een extra vertaling maken voor de DRC API rondom bestandsdelen.

Het enige wat we niet vatten is hoe dit Technisch & Functioneel bedacht is?

• Stel je hebt een mis-match in volgnummers, bijv 0,1,3,4  wat dan?
• Is het de taak van de DRC om de kwaliteit te bewaken? Stel iets is niet compleet of niet goed, dan gooit hij dat magisch weg of is de Client verantwoordelijk dat de data goed is?
• Is een 2e request op de bestanddeel gewoon een versie update?

Ik denk dat we het niet begrijpen, maar het lijkt alsof er iets complex is gekozen voor iets heel simpels, namelijk naast base64 ook de mogelijkheid te geven om het multi-part aan te bieden.

[shazada]

@michielverhoef kun je hier nog op reageren? het is al enige tijd geleden en we gaan deze impediment niet implementeren als hier geen duidelijkheid over is.

[michielverhoef]

Technisch gesproken is dit geen impediment. Tenminste, niet in de zin dat het iets is wat het ontwikkelen van de standaard in de weg staat. ;-)

De vragen die je stelt zijn goed en ik ga kijken of ik ze beantwoord kan krijgen. Kunnen we dit volgende week kort bespreken? Ik neem wel even off line contact op.

[shazada]

Prima ik wacht op je contact.

[shazada]

Het is al meer dan 5 maanden geleden, maar ook omtrent verschillende meldingen is er 0 contact geweest vanuit @michielverhoef graag hier prio aan geven. Onze DRC met Tezza staat al bij 5 klanten live, dus kunnen niet zomaar dingen aanpassen omdat daar niet goed vooraf ook met ons is nagedacht. Persoonlijk vind ik ook dat er onvoldoende contact is tussen VNG en leveranciers en team Open-Zaak (iedere kwartaal is er een sessie, maar niemand van VNG zit daar bij).

Dus ik zou niet weten hoe je dit gezond wil oplossen. Graag hoor ik snel van je en verwacht ik een bel of een meetingverzoek.

[michielverhoef]

OpenZaak is een product van leveranciers, daar gaat VNG niet bij aansluiten. We sluiten ook niet aan bij vergaderingen van andere leveranciers. Dit heb ik al eerder aangegeven.

Wat ik me afvraag: Waarom zou je een vertaling tussen DRC 1.1 en DRC 1.0 willen maken? Het grote verschil is het gebruik van bestandsdelen in DRC 1.1 maar dat is niet verplicht. Je kunt nog steeds inhoud uploaden met een base64 encoded bestand.

Dat er dingen onduidelijk zijn mbt het multipart verhaal in de Documenten API heb ik ook benoemd in #2257 . Overigens begin ik het nu te snappen. Wat wel duidelijk is is dat de documentatie flink verbeterd moet worden.

Terug naar je oorsponkelijke vragen:

• Stel je hebt een mis-match in volgnummers, bijv 0,1,3,4  wat dan?

Als ik de documentatie nalees is het de verantwoordelijkheid van de consumer om de juiste bestandsdelen aan te bieden aan de url's die met de POST van het enkelvoudiginformatieobject aangemaakt worden. In de beschrijving in de OAS staat:

Bestanden kunnen groter zijn dan de minimale die door providers ondersteund moet worden. De consumer moet dan:

Het INFORMATIEOBJECT aanmaken in de API, waarbij de totale bestandsgrootte meegestuurd wordt en de inhoud leeggelaten wordt. De API antwoordt met een lijst van BESTANDSDEELen, elk met een volgnummer en bestandsgrootte. De API lockt tegelijkertijd het INFORMATIEOBJECT.
Het bestand opsplitsen: ieder BESTANDSDEEL moet de bestandsgrootte hebben zoals dit aangegeven werd in de response bij 1.
Voor elk stuk van het bestand de binaire data naar de overeenkomstige BESTANDSDEEL-url gestuurd worden, samen met het lock ID.
Het INFORMATIEOBJECT unlocken. De provider valideert op dat moment dat alle bestandsdelen correct opgestuurd werden, en voegt deze samen tot het resulterende bestand.

De consumer moet dus zelf de bestandsdelen aanmaken en op de juiste wijze uploaden.

• Is het de taak van de DRC om de kwaliteit te bewaken? Stel iets is niet compleet of niet goed, dan gooit hij dat magisch weg of is de Client verantwoordelijk dat de data goed is?

De client is verantwoordelijk. Al is het wel zo dat bij het aanmaken van een multipart document door de provider berekend wordt hoeveel delen er zullen worden geupload. Dus als de client niet voldoende upload kan de provider de delen niet samenvoegen tot 1 geheel.

• Is een 2e request op de bestanddeel gewoon een versie update?

Zoals ik de uitleg in de OAS begrijp worden bestandsdelen samengevoegd en bestaan deze daarna niet meer. Om een nieuwe versie te maken moet een PUT of PATCH van het enkelvoudiginformatieobject gedaan worden en de provider geeft dan nieuwe urls voor de bestandsdelen die geupload moeten worden.

[shazada]

Duidelijk! @michielverhoef
Dit stukje tekst:
Kan dit niet toegevoegd worden aan de documentatie:
Zoals ik de uitleg in de OAS begrijp worden bestandsdelen samengevoegd en bestaan deze daarna niet meer. Om een nieuwe versie te maken moet een PUT of PATCH van het enkelvoudiginformatieobject gedaan worden en de provider geeft dan nieuwe urls voor de bestandsdelen die geupload moeten worden.

[michielverhoef]

@shazada ga ik zeker doen!