You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Componenten die APIs aanbieden (ZRC, DRC, ZTC) moet aan volledige inputvalidatie doen. Dit betekent dat er meer validatie nodig is dan enkel garanderen dat een veld aan het url-formaat voldoet, en dat er communicatie tussen systemen is in het geval van gedistribueerde componenten.
Een concreet voorbeeld hiervan is het zetten van een STATUS op een ZAAK:
Het aanmaken van een status gebeurt door een nieuwe status te POSTen, met onder andere de URL van het statusType.
Het ZRC MOET deze statusType url opvragen uit het ZTC, en controleren dat het zaaktype van dit statustype overeenkomt met het zaaktype van de betreffende zaak.
De foutberichten voor deze validatie zullen opgesteld worden en opgenomen in de API spec.
Noot: voor suites kan de implementatie hiervan uiteraard afwijken - indien alles in 1 enkele database leeft, en de suite ontsluit 3 APIs, dan kan prima de validatie intern gebeuren op een geoptimaliseerde manier. Belangrijk is dat de fout-responses (zie ook #130) correct teruggegeven worden.
Noot 2: authenticatie en authorisatie worden in een later stadium uitgewerkt. Het is bekend dat hier goed over nagedacht moet worden.
The text was updated successfully, but these errors were encountered:
MV: Noodzakelijk om te garanderen dat federatief opgeslagen gegevens kloppen.
RM: Deze DD (maar wellicht ook andere) zo documenteren dat niet meer duidelijk is uit welk domein ze oorspronkelijk ontsproten zijn. In dit geval moet ZRC, DRC en ZTC slechts als voorbeeld genoemd worden.
Ik vraag me overigens af of het wel een Design Rule betreft. Wellicht meer een Design Rule voor een provider systeem.
JBo: Hiermee stel je een eis aan de verwerkende referentiecomponent. Dat is geen Design Decision voor de API in mijn beleving. Gaarne discussie
GJ: Niet een generieke API design decision, maar meer een implementatie aspect.
Componenten die APIs aanbieden (ZRC, DRC, ZTC) moet aan volledige inputvalidatie doen. Dit betekent dat er meer validatie nodig is dan enkel garanderen dat een veld aan het url-formaat voldoet, en dat er communicatie tussen systemen is in het geval van gedistribueerde componenten.
Een concreet voorbeeld hiervan is het zetten van een STATUS op een ZAAK:
Het aanmaken van een status gebeurt door een nieuwe status te POSTen, met onder andere de URL van het statusType.
Het ZRC MOET deze statusType url opvragen uit het ZTC, en controleren dat het zaaktype van dit statustype overeenkomt met het zaaktype van de betreffende zaak.
De foutberichten voor deze validatie zullen opgesteld worden en opgenomen in de API spec.
Noot: voor suites kan de implementatie hiervan uiteraard afwijken - indien alles in 1 enkele database leeft, en de suite ontsluit 3 APIs, dan kan prima de validatie intern gebeuren op een geoptimaliseerde manier. Belangrijk is dat de fout-responses (zie ook #130) correct teruggegeven worden.
Noot 2: authenticatie en authorisatie worden in een later stadium uitgewerkt. Het is bekend dat hier goed over nagedacht moet worden.
The text was updated successfully, but these errors were encountered: