Uniformiteit in __in query parameters

[frank1230873]

Bug

https://github.com/VNG-Realisatie/gemma-zaken/blob/master/api-specificatie/zrc/current_version/openapi.yaml regel 6581 (query parameter archiefnominatie__in). Hier is het type van de __in parameter een array.

https://github.com/VNG-Realisatie/gemma-zaken/blob/master/api-specificatie/ztc/current_version/openapi.yaml regel 1251 (query parameter domein__in). Hier is het type van de __in parameter een string.

Graag zou ik hier uniformiteit in zien zodat we in beide situaties de afhandeling gelijk kunnen trekken. Mijn persoonlijke voorkeur gaat uit naar string, omdat dotnet (onze implementatie) niet goed met de array om kan gaan. Maar de uniformiteit is het belangrijkst :).

[frank1230873]

Ik zie nu dat het ook voor de ordering query parameter geldt :). Ik denk dat die op dezelfde manier zou moeten werken als een __in filter

[HenriKorver]

Beide stijlen (als type string of array) om een comma seperated list van waarden te specificeren voor een query parameter zijn toegestaan. De laatste stijl (array) is volgens mij het beste en die is blijkbaar pas later in gebruik genomen waardoor er nu twee verschillende stijlen zijn die in de OAS gebruikt worden. Ik zie dit niet als een bug omdat deze inconsistentie van specificatie-stijl geen invloed heeft op de standaard. Al zouden we de stijlen willen rechttrekken in een volgende versie dan zou ik kiezen voor array.

Vreemd trouwens dat de dotnet tooling last heeft van array want dat is veel explicieter dan type string. In geval van type Array kan de codegenerator meteen weten dat ie comma sperated list moet genereren voor query parameters met meerdere waarden.

[frank1230873]

Het probleem met dotnet zit niet in de generatie, want die geeft wel mooi een array terug. Maar als er vervolgens een waarde "test1,test2" wordt meegegeven, dan komt het geheel in het eerste element terecht. Ik zal eens zoeken waar dat aan kan liggen.