Spectral-Regel für Casing von Pfad- und Query-Parameter
User Story
Why
Übernahme von https://github.com/italia/api-oas-checker/pull/410/files. Entweder durch Update der Italinischen Regeln oder als eigenständige, zusätzliche Regel.
-
Prüfen ob einer der APIs gegen diese Regel verstößt, falls nicht, dann -
Regel ist in der CI der Submission API integriert -
Regel ist in der CI der Routing API integriert -
Regel ist in der CI der Destination API / Self-Service API integriert -
[ ] Regel ist in der CI der DVDV -- FIT-Connect API integriert (des DVDV Microservices)(nicht möglich, gegen die query-parameters-camelcase-Regel wird verstoßen)
-
Links, Notes, Remarks
aus #1585 Aktuell haben wir keine Linting-Regel für unsere OpenAPI-Specs, die sicherstellen würde, dass die Namen von Query- und Pfadparametern in camelCase sind.
Es besteht das Risiko, dass Parameter in inkonsistentem Case eingeführt werden.
Eine Lösung wäre, die in #213 (closed) beschriebenen custom rules in unsere 3 Repositories zu kopieren.
Zur Bewertung ist zu sagen, dass diese Überprüfung schon nützlich sein könnte, weil Parameter oft vorkommen und sich deshalb Fehler einschleichen können. Nachteilig wäre, dass redundante Code-Blöcke in 3 Repositories kopiert würden. Alles in allem würde ich die Umsetzung vom Vorschlag aus #213 (closed) aber schon für sinnvoll erachten.
Acceptance criteria
-
... -
... -
...
Implementation plan (to be completed by the developer)
-
... -
... -
... -
Definition of Done was checked.