Ungelöst Openjson Fehler: person/masterdata
-
Das Schema hat sich in Openapi 3.0 gegenüber Openapi 2.0 geändet. Das hier verwendete Format führt zu keinem Fehlern bei der Generierung, aber bei der Verwendung der API.
Seit der Version 3.0 mussenum
innerhalb vonschema
verwendet werden.Konkret geht es um die
contactLabels
in der API-Schnittstelle person/masterdata. Und darin um das propertyìsDefault
. Laut derzeitiger openapi.json Beschreibung sieht es so aus:"isDefault": { "type": "boolean", "enum": [ "true", "false" ], "example": "false", "description": "Indicator if label is the default. Used for new person emails" }
Es sollte aber geändert werden in:
"isDefault": { "schema": { "type": "boolean", "enum": [ true, false ] }, "example": "false", "description": "Indicator if label is the default. Used for new person emails" }
Die "alte Definition" führt dazu, dass bei der Evaluierung der Ergebnisse in der API als Antwortwerte lediglich zwei Strings erlaubt sind (mit den Werten "true" oder "false", als String). Boolsche Werte werden im Ergebnis als fehlerhaft gewertet und es wird eine Exception geworfen.
Siehe auch https://swagger.io/docs/specification/data-models/enums/
Oder noch besser:
Nach meinem Verständnis bräuchte es in der Openapi.json bei boolean Werte gar kein
enum
. Per Definition können Werte vomtype
boolean nämlich nurtrue
oderfalse
sein.
So steht es jedenfalls hier: https://swagger.io/docs/specification/data-models/data-types/#booleanHinweis:
Die Änderung muss auch an allen andereren Stellen gemacht werden, wo in der Openapi ContactLabels zum Einsatz kommen. Außerdem habe ich ähnliche Definitionen noch an anderen Stellen gefunden, wie z.B. bei
- /songs >> arrangemens >> isDefault
- /songs/{songId} >> Song >> shouldPractice
- ...
-
Ich finde diese Seite sehr hilfreich um den Unterschieden zwischen der Spezifikation in 2.0 und 3.0 grafisch nachzugehen:
https://openapi-map.apihandyman.io -
@skipy sagte in Openjson Fehler: person/masterdata:
Oder noch besser:
Nach meinem Verständnis bräuchte es in der Openapi.json bei boolean Werte gar kein enum. Per Definition können Werte vom type boolean nämlich nur true oder false sein.Du steigst da gut und tief ein. Vielen Dank. Es sind oft diese Kleinigkeiten, die einem das Leben schwer machen. Ähnliche Probleme gibt es manchmal mit IDs, die mal als Integer und mal als String zurückkommen.
Apropos Bool: Ich persönlich würde ja empfehlen auf bool ganz zu verzichten. Irgendwann kommt mal ein Fall hinzu wo man nicht mehr nur zweiwertig unterwegs ist. In der Regel braucht noch noch einen Neutralwert wenn man da nicht null nehmen will. Daher fände ich das mit den enum schon besser (und zukunftssicherer)