Meine Herren!

Nein, du wählst einen spezialisierten Ansatz, der nicht verträglich mit bestehenden Konzepten und Denkweisen ist. Es muss ensteht für den Entwickler ein echter Mehraufwand, aber ohne dabei einen qualitativen Mehrwert zu Leisten.

Nicht verträglich betrifft nur den Transport.

Nein, das betrifft sehr vieles. Das erste Problem ist, dass man aus dem puren HTML-Quelltext bei dir nicht mehr instinktiv sagen kann, welche Daten überhaupt verschickt werden. Ein Webseiten-Entwickler wird als erstes einen Blick auf die Namen und Werte der Formular-Felder werfen, er wird nicht davon ausgehen, dass auch Klassennamen an den Server geschickt werden. Das ist auch unnatürlich. Das wird von keiner bestehenden Formular-Kodierung gemacht. Das ist kognitiver Workload, den der Entwickler aufbringen muss, um sich deinen Ansatz hinein zu denken. Bei reglementierten Kodierungen, gibt es diesen nicht.

Und das ist ein schwerwiegendes Problem: Weil man das Standard-Verhalten einfach aushebelt, müssen Integrations-Tests vorgenommen werden. Und deine bisherige Implementierung würde da eiskalt durchfallen: Du hebelst nämlich die gesamte Formular-Validierung aus und erzeugst so eine riesige Barriere. Jetzt, da du das weißt, kannst du deine Implementation anpassen, aber der Punkt sollte deutlich werden: Standard-Verhalten zu deaktivieren ist eine gefährliche Sache.

Die nächste Inkompatibilität ist technischer Natur: Mit den nativen Möglichkeiten eines Browsers ist es nicht möglich ein Formular in deiner Kodierung zu versenden. Es muss clientseitig erst Code geschrieben werden, damit das ermöglicht wird.

Das selbe Spiel muss auch auf dem Server gespielt werden, auch dort muss Code geschrieben werden damit deine Kodierung erkannt wird. Und da ergibt sich sofort das nächste Problem: Der notwendige Dekodierungs-Algorithmus wird üblicherweise über den übermittelten MIMEType ausgehandelt, das ist nicht möglich, weil du keinen expressiven MIMEType überträgst. Es muss also eine Ausnahmebehandlung extra für deinen Kodierung übermittelt werden. Es gibt kein objektives Kriterium, an dem Mann überhaupt feststellen könnte, ob deine Dekodierung angewandt werden müssten. In einem kleinen Software-Projekt ist das okay, du weißt ja schließlich was ankommt, und wie damit zu verfahren ist. In größeren Software-Projekten ist das nicht tragbar.

Die Datenstrukturen bleiben dieselben, egal ob mein Serializer EAV.js oder JSON zum Einsatz kommt. D.h., der Transport-Layer ist austauschbar.

Was verstehst du unter dem Transport-Layer? Ich glaube nicht, dass du auf TCP hinaus möchtest. Ich weiß auch nicht, wie sich diese Aussage mit deinem ersten Satz "Nicht verträglich betrifft nur den Transport" vertägt.

Unabhängig davon, die Datenstrukturen werden schon vor der Übertragung durch die Kodierung verändert. In dem Beispiel aus meinem letzten Beitrag habe deutlich gemacht, dass application/json etwa das Konzept von hierarchischen Datenstrukturen kennt, application/x-www-form-urlencoded kennt dies nicht. Wie sollen diese beiden Kodierungen eine verträgliche Repräsentation finden?

Den Rest deiner Antwort, werde ich mir morgen vorknüpfen ;) Bin gerade leider abkommandiert worden, um ein Bier mit Freunden zu trinken.