Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Input validatie velden met url-formaat #96

Open
melsk-r opened this issue May 27, 2021 · 1 comment
Open

Input validatie velden met url-formaat #96

melsk-r opened this issue May 27, 2021 · 1 comment
Labels
Design Rule Bespreekpunten om al dan niet op te nemen in de VNG-Design Rules

Comments

@melsk-r
Copy link
Contributor

melsk-r commented May 27, 2021

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.

@melsk-r melsk-r added the Design Rule Bespreekpunten om al dan niet op te nemen in de VNG-Design Rules label May 27, 2021
@melsk-r
Copy link
Contributor Author

melsk-r commented May 27, 2021

JBo: Discussie
HK:
RM: Discussie
MV: Overnemen
GJ: Niet overnemen
JBi: Bespreken

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Rule Bespreekpunten om al dan niet op te nemen in de VNG-Design Rules
Projects
None yet
Development

No branches or pull requests

1 participant