Voeg regel toe voor error structuur bij Bad Requests

[TimvdLippe]

Hier was initieel geen consensus voor bij de behandeling van het hoofdstuk "Error Handling".

[github-actions]

Preview link voor pull request
Diff met W3CDiff

[TimvdLippe]

Deze wijziging is gedeeltelijk goedgekeurd op het TO API van 2026-03-03. Alle regels behalve /core/error-handling/bad-request zijn goedgekeurd. Voor deze laatste regel wordt de discussie verder gevoerd met inachtneming van de input van Kadaster over hun huidige omgang van error handling (CC @strijm). Hier zal er expliciet worden gekeken naar de huidige oplossing bij Haal Centraal en worden gekeken naar:

1. Het mogelijk hernoemen van errors naar invalid-params
2. Analyseren van impact van name vervangen door location
3. Kijken hoe de gedetailleerde specificatie van error handling in .feature bestanden bij Kadaster te vatten is in de structuur

#251 (comment)

Het mogelijk hernoemen van errors naar invalid-params

Dit lijkt me niet wenselijk, omdat je een JSON property niet kunt beschouwen als een "param" (in tegenstelling tot query en header parameters). Hier zit dus een semantische mismatch. Om deze reden was gekozen voor de algemenere term errors, in lijn met de voorbeelden in de RFC en bijv ook in dit blog.

Analyseren van impact van name vervangen door location

Het gebruik van name impliceert een enkelvoudige naam van een top-level property (in het geval van een body value). Dat lijkt ook de manier waarop het in de genoemde API's wordt gebruikt. Je wil echter ook errors kunnen rapporteren voor dieper gelegen waardes (zoals nested object properties of array items). Vandaar dat er gekozen is voor de bredere term location die voor body values een locator van de value verwacht (JSON Pointer voor JSON, XPath voor XML). Voor parameters is de waarde van location enkel de naam.

@joostfarla in #251 (comment)

Mogelijkheden voor naamgeving van het JSON veld:

1. "errors"
2. "invalid-params"
3. "invalid-input"