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

Response bij input validatie #98

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

Response bij input validatie #98

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

De DSO schrijft een structuur voor waar een fout-response aan moet voldoen in het geval van validatiefouten:

{
    "type": "...",
    "title": "...",
    "status": 400,
    "detail": "...",
    "instance": "...",
    "invalid-params": [{
        "type": "...",
        "name": "<veldnaam>",
        "reason": "Maximale lengte overschreden.",
    }]
}

Op het forum is nagevraagd hoe er moet worden omgegaan met meerdere fouten op hetzelfde veld, met de conclusie dat dit beter gespecificeerd moet worden.

In de ZGW API’s kiezen we ervoor om elke fout op een veld als apart object op te nemen binnen de "invalid-params" sleutel. Dit laat clients toe om elke individuele fout te renderen zoals zij wensen.

Tevens voegen we op het hoofdniveau van fout-responses en binnen een object in "invalid-params" een sleutel "code" toe. Dit veld bevat een waarde die door machines begrepen kan worden, bijvoorbeeld "invalid" of "max_length_exceeded". De "type" sleutel is namelijk optioneel en bedoeld voor developers om meer informatie over het fouttype te lezen, en niet voor automatische verwerking.

Een voorbeeld response is dan:

{
    "type": "URI: https://zaken-api.vng.cloud/ref/fouten/ValidationError/",
    "title": "Ongeldige gegevens",
    "status": 400,
    "code": "invalid",
    "detail": "Er deden zich validatiefouten voor",
    "instance": "urn:uuid:2d3f8adb-470d-4bf4-8c43-4b2ebeef7504",
    "invalid-params": [
        {
            "name": "identificatie",
            "code": "max-length",
            "reason": "Maximale lengte overschreden.",
        },
            {
            "name": "identificatie",
            "code": "special-characters",
            "reason": "De identificatie mag geen speciale karakters bevatten.",
        }
    ]
}

Merk op dat de concrete codes hier fictief zijn en puur ter illustratie zijn.

@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: Gaarne bespreken.
HK:
RM: Meer input nodig
MV: Overnemen
GJ: Overnemen
JBi: Klinkt logisch.

MV: Klinkt logisch voor API's waar gegevens geschreven worden
RM: Mee eens alhoewel ik wel heel nieuwsgierig ben naar de mening van bijv. een Melvin.
GJ: RFC7807 geeft voldoende grondslag. Wel benieuwd of meerdere fouten worden geacht voldoende gelijkend te zijn zodat deze passen bij de hoofdfout?

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