Als developer wil ik weten bij opvragingen/GETs hoe omgegaan wordt met optionele velden (en welke velden optioneel zijn)

[alextreme]

In overleg met Atos/e-Suite over OpenZaakBrug en in verlengde van discussies binnen Den Haag en bij ons intern, zou ik op 1 onderdeel van de standaard willen uitweiden. Ik zag dat in #2090 recent dit ook door Roxit is aan gerefereerd.

De huidige standaard geeft aan welke waarden wel en welke niet required zijn voor een create-POST en hoe je die dan mee kan geven, echter het is vanuit de standaard niet helder hoe de list/detail-GETs eruit zien. Consensus intern en met Atos is dat je in ieder geval mag uitgaan dat de required-velden in de POSTs zullen terugkomen bij een opvraging, echter expliciet is beter dan impliciet dus dit lijkt mij een handige verduidelijking.

Ingewikkelder wordt het bij optionele velden, bijvoorbeeld voor veld 'omschrijving' bij een zaak. Deze is als niet required string-veld optioneel om mee te sturen bij het aanmaken van een zaak. Er zijn dan echter 3 mogelijke antwoorden bij een opvraging:

• 'omschrijving' wordt niet teruggestuurd (string-veld zit alleen in het antwoord indien ingevuld)
• 'omschrijving' is een lege string (veld zit altijd in het antwoord, maar kan een lege string zijn indien niet ingevuld)
• 'omschrijving' is een null-waarde (veld is een string indien ingevuld, anders is omschrijving=null)

Wellicht dat het ook handig is om een minimale response als voorbeeld naast de huidige volledige response ter voorbeeld op te nemen in de OAS of documentatie. Daaruit is bovenstaande volgens mij ook goed af te leiden.

[WilliamRoxit]

Wat meer duidelijkheid hieromtrent is inderdaad erg fijn.

Ik verwacht eigenlijk alle niet-nullable velden terug in een get. Ongeacht of ze 'required' zijn bij een post of niet; behalve required velden die nullable zjin, die mogen m.i. niet voorkomen. Wat ik vaak verwarrend vind is dat het kenmerk required op de resource is gedefinieerd terwijl het niks zegt over de resource, maar over het request. Bijvoorbeeld velden die bij een post required zijn om een resoure aan te maken; zijn dan ook ineens required bij een patch; terwijl het doel, zoals ik het zie, is om bij het initieel aanmaken van een resource een aantal required velden te specificeren die nodig zijn voor het aanmaken, maar voor bijv. een patch is dat onzinnig.

Wat betreft de bulletpoints: imho is het niet sturen van een veld in een bericht hetzelfde als het veld weglaten. Ik verwacht dan ook dat als bijv. omschrijving bij een post weggelaten wordt, dit hetzelfde behandeld wordt als null en ik in de get dus ook gewoon null terugkrijg. Post ik een lege string, dan zal ik een lege string terugkijgen. Persoonlijk behandel ik een lege string ook als een waarde en enkel null als geen waarde.

Benieuwd hoe @alextreme hier tegen aan kijkt?

[alextreme]

@WilliamRoxit ik zit hier neutraal in, het is mij om het even zolang de werking per veldtype vastgelegd wordt in de standaard en ik met een ZGW client niet om hoef te gaan met de situatie dat bijvoorbeeld een stringveld in een response of kan ontbreken, of een lege string kan zijn, of null kan zijn. Want die variatie zien we nu wel ontstaan en het zal interoperabiliteit in de weg zitten.

@joeribekker heb jij hier nog een mening over?

[michielverhoef]

Dit lijkt me een goed onderwerp voor de technische gebruikersgroep op 28 september, met deze discussie als input.