Commentaar bij de berichtenstandaard

[johannesbattjes]

Commentaar bij de berichtenstandaard

Commentaar op specifieke velden in POST bericht:

• Batchid komt vanuit Logius batch. Maar in een Rest Api zijn er geen batches. Voorstel: laten vervallen
• Berichttype: onduidelijk wat dit is. Voorstel: weglaten
• wat is publicatiedatum? Met REST Api's is het bericht er meteen. Voorstel: hernoemen naar datum verzending
• inhoud: er is maar 1 inhoud dus 1 bijlage mogelijk. Voorstel: array van bijlages
• inhoud: is nu base64. Voorstel: in plaats daarvan referentie naar DRC (url)
• berichttekst: wat is het formaat. voorstel: specificeer een formaat. Bijvoorbeeld HTML, Markdown.
• bijlagetype: is nu een extensie met één waarde. Voorstel: sta toe wat DRC toe staat (de Iana lijst van mimetypes). Maar dat hoeft geen apart veld in het bericht te zijn als er referenties naar de DRC komen.
• referentie: kan maar 25 tekens bevatten. Maar een zaaknummer bevat meer. Het zouden 40 tekens moeten kunnen zijn zoals bij zaakidentificatie. Maar zaaknummer kun je ook ophalen vanuit ZRC, dus is overbodig. Voorstel: laten vervallen.
• gebruikerID/gebruiker: dit kan nu alleen één ontvanger zijn (een burger). Maar ook bedrijven moeten kunnen ontvangen en de gemeente zelf (in een antwoordbericht). Voorstel: laat deze velden vervallen.
• partij: niet duidelijk wat de rol is. Voorstel: maak duidelijk wat de rol is van de partij. (Ontvanger, verzender, cc).
• partij: is heel anders vorm gegeven dan in ZGW. Voorstel: modelleer naar ZGW dus op basis van de roltypes (vestiging, natuurlijk persoon, nietnatuurlijkpersoon, medewerker). Laat alleen identificerende gegevens toe en laat alle overbodige adres/contactgegevens achterwege om gegevensverdubbeling te minimaliseren.
• Partij: er is sprake van vertegenwoordiging maar ZGW gebruikt gemachtigde en machtiginggever. Voorstel: term aanpassen.

Ontbrekende velden (voorstel: toevoegen):

• link naar zaak (ZRC-url)
• link naar besluit (BRC-url)
• links naar bijlages (DRC-url)
• richting (vanuit zaakbehandelaar naar andere zaakbetrokkene/ontvanger of vanuit ontvanger naar zaakbehandelaar)
• toelichting per bijlage (wat is het)

Interactie

• het lijkt of alleen de gemeente kan zenden. Maar de ontvanger moet ook een bericht terug kunnen sturen. Voorstel: maak berichten in twee richtingen mogelijk, en hou deze samen met een entiteit "thread" of "conversatie".
• links naar zaken en documenten. Het moet ook mogelijk zijn voor een ontvanger om documenten (resulterend in link naar DRC) toe te voegen.
• sta meerdere ontvangers toe.
• er is geen link met taak en vice versa. Maar als je iemand een taak geeft hoort daar een bericht bij. Bijvoorbeeld: voor aanvullende stukken wil je een bericht sturen op dezelfde manier als andere berichten om alles uit te leggen, en tevens is het een taak. Voorstel: een taak kan niet zonder bericht bestaan (maar je hebt wel berichten zonder taak). Voorkom gegevensverdubbeling tussen taak en bericht.

Redoc zelf

• patch: wanneer kun je patchen? Een verzonden bericht zou je niet zomaar moeten kunnen aanpassen.
• delete: wanneer kun je verwijderen? Een verzonden bericht zou je niet zomaar moeten kunnen verwijderen.
• partij: bevat oneindige nesting. Beter niet doen.
• partij: beter apart aanmaken met POST en dan referentie meegeven in Bericht.
• de beschrijving van Partij staat er meerdere malen drie keer in en vol vraagtekens.
• GET bericht (lijst): kan niet gefilterd plus geeft hele berichtinhoud terug. Wordt onbruikbaar als een organisatie tienduizenden berichten heeft.
• niet duidelijk welke velden optioneel of nullable zijn.

[github-actions[bot]]

👋 @johannesbattjes Thank you for raising an issue. We will investigate the matter and get back to you as soon as possible. Please make sure you have given us as much context as possible.