Übersicht Validation Frameworks
Nach erster Sichtung sehen Colander und Cerberus geeignet aus.
D.h. wir bräuchten eine einfache Implementierung der Eckpunkte mit beiden, um dann zu entscheiden, welche wir haben wollen. ^^
Ja, da hab ich auch schon drüber nach gedacht und bin noch nicht zu einem befriedigenden Ergebnis gekommen. An sich würde ich auch gern eine Möglichkeit vorsehen, um der Antwort ein finding mitzugeben, damit der Nutzer nicht nur mit einem roten Licht da steht...
Ja, dazu wollte ich die API auch noch einmal anpassen. Wir brauchen eine schönere Möglichkeit, um einerseits Fehler und Warnungen zu unterscheiden und andererseits strukturierter zu sagen, worauf sich eine Meldung bezieht. Derzeit können wir pro Feld maximal einen Fehler zurückgeben.
Ich habe hier noch nicht geantwortet, denke aber auch schon seit zwei Wochen drauf rum.
Grundsätzlich finde ich es gut, die Validatoren flexibel zu halten. Zwei Dinge halten mich von der Lösung ab:
- Das JSON zieht eine Zwischenschicht in den sonst recht einfachen Validator-Code ein. Wir müssen nun auch das JSON interpretieren (und validieren).
- Es ist auf diese Art keine komplexe Validierung möglich, weil immer von den einzelnen Feldern ausgegangen wird, wir aber ggf. auch über Gruppen von Feldern validieren wollen. (Man könnte z.B. warnen, wenn ein Mitglied keine Kontoverbindung hat, das ist aber nur relevant, wenn die Mitgliedschaft auch noch besteht. Es gibt bei den Verbundfeldern sicherlich auch noch trivialere Fälle.)
Gibt es vllt einfach nutzbare Bibliotheken zur Validierung, die man dann z.B. auch über ein JSON füttern kann?
Ansonsten würde ich hier direkter entwickeln und die Validierungsfälle in Python-Code schreiben. Unser Schema ist recht statisch und wir haben auch nicht den Fall, dass wir ein Framework entwickeln. Die übertragung der Validierung an einen Remote-Service ist ebenfalls kein Thema, weil der Remote-Service hier schon aufgerufen wurde.
Dieser PR ist für mich eigentlich okay, ich denke nur noch über eine Sache nach: Wenn die Validatoren sowieso in einem Unterverzeichnis sind, warum dann nicht auch in getrennten Dateien?
Ist es evtl sinnvoll, gleich ein Python-Modul daraus zu machen?
@dkdent Ich habe ein paar Korrekturen vorgenommen (!fixup-Commits). Insbesondere brauchen die Module keine Shell-Infos zur Ausführung.
Wenn Du mit den Änderungen einverstanden bist, kannst Du die Commits so zusammenfassen:
git rebase -i --autosquash master
git push --force-with-lease
Wenn --force-with-lease fehlschlägt, hast Du nicht den neusten Repostand.
PR ist jetzt dort: https://gitea.n39.eu/Netz39_Vorstand/entities_validation_svc/pulls/1
So weit ich das sehe, muss die Benutzung auch nicht wirklich authentifiziert passieren. Da bekommt man keine geschützten Daten raus, oder?
Es gibt zwei Aspekte für einen Schutz:
- Rechenlast, falls jemand die Schnittstelle spammt
- Evtl Quota/Kosten, wenn wir Bankdaten prüfen
Eine Authentifizierung später einzuführen, ist schwierig.
Außerdem könnte die Validierung ein eigenständiger Service sein. Das ist interessant, wenn die Validierung der Bankdaten eingebunden wird.