Als consumer wil ik een resource 'zaakdossier'...

[sergei-maertens]

...zodat alles wat bij een zaak hoort inzichtelijk is.

We hebben nu verschillende resources die zich op verschillende manier verhouden tot zaak. In het kader van archiveren (en dan vooral vernietigen), is het belangrijk dat een zaakdossier volledig vernietigd wordt.

Indien we de business logica van 'wat is een zaakdossier' neerleggen bij de consumer, dan bezorgt dit de developers van consumers onnodig werk - op het moment dat er een resource toegevoegd wordt die zich verhoudt tot zaak en meevernietigd moet worden, dan zien er code-aanpassingen nodig bij consumers die het opvragen en verwijderen van deze nieuwe resource implementeren.

Dit kunnen we voorkomen via een zaakdossier resource - deze resource kan opgevraagd worden met de URL van de zaak, en zou in een gestructureerd formaat URL-referenties bevatten naar alle gerelateerde resources die op een generieke manier opngenomen worden en dus kunnen vernietigd worden. Het is aan de providers om deze lijst correct op te stellen.

Een concreet voorbeel van hoe dit eruit kan zien:

{
    "url": "https://example.com/zrc/api/v1/zaakdossiers/3a22f2b1-eb40-4950-bb32-665c37f5e397",
    "zaak": "https://example.com/zrc/api/v1/zaken/3a22f2b1-eb40-4950-bb32-665c37f5e397",
    "gerelateerdIntern": [
        "https://example.com/zrc/api/v1/statussen/0b363252-7618-4d71-bac1-51d882de6a18",
        "https://example.com/zrc/api/v1/statussen/591b0638-baec-4148-b355-14cc25745d37",
        "https://example.com/zrc/api/v1/rollen/e27c292a-98d1-41ba-9937-7408ce15a986",
        "https://example.com/zrc/api/v1/eigenschappen/cd3c2e2b-8ba3-4ce3-a617-a4ef9265177b",
    ],
    "gerelateerdExtern": [
        "https://example.com/brc/api/v1/besluiten/79c85cbe-104b-4ed8-9d67-55fe7f6f8d08",
        "https://example.com/drc/api/v1/objectinformatieobjecten/1dc300eb-5e53-44d1-a053-7450aa21d3cf",
    ]
}

Een client-implementatie zou dan eenvoudig geimplementeerd zijn als:

import requests

for related in zaakdossier['gerelateerdExtern']:
    requests.delete(related)

en nooit aanpassingen vereisen als resources toegevoegd en/of verwijderd worden.

Bepaling prioriteit door PO

• verbreding of verdieping API's
• stimuleert gebruik door gemeenten
• stimuleert gebruik door leveranciers

... eventueel nog toelichting door PO

Definition of ready

• Iedereen in het team begrijpt de user story
• de gewenste (aanvulling op de) functionaliteit van de API's duidelijk en beschreven is.
• Is klein genoeg (maximaal 1/5 van sprint)
• Product Owner akkoord en voorzien van prioriteit (mag alleen afgevinkt worden door PO)
• Idee hebben van hoe deze user story kan worden gedemonstreerd.
• Userstory is voorzien van een analyse (met daarin architectuur, IM, technische beslissingen afgestemd met team)
• Vastgelegd in Github en geplaatst in kolom ready

Definition of done

• Er is een OAS 3.0 specificatie
• Er is een referentieimplementatie
• Er zijn tests aanwezig die de wijziging aantonen
• De technische specificatie (standaard.md) is gepubliceerd leesbaar

Acceptatiecriteria

• De DSO URI- en API-strategie worden gevolgd of afwijkingen zijn vastgelegd als ontwerp keuze
• Eventueel gemaakte ontwerp keuzes zijn gedocumenteerd
• Er zijn geen bekende GEMMA tegenstrijdigheden of afwijkingen zijn vastgelegd.

Taken

• Implementeren in referentie-implementatie [verantwoordelijke]
• Schrijven (unit) test voor referentie-implementatie [verantwoordelijke]
• Genereren/opstellen van OAS 3.0 [verantwoordelijke]
• Human Readable publiceren Open API Specificatie (v.3.0) [verantwoordelijke]