Meine Herren!

Welcher Parser?

Oops, ich denke Du solltest Dir mal angucken, wie der Enctype="multipart/form-data"

Ach du redest vom Request-Body der HTTP-Anfrage. Benenn ihn doch so ;)

der so ein vorsintflutliches Vehikel erstmal temporär auf die Platte schreibt um es dann in seine Einzelteile zerlegen zu können anhand der Boundary die im Request-Header mitgesendet wird.
Erst dann liegen die einzelnen Komponenten mit definierten Content-Types vor, egal ob der Parser PHP oder Perl redet.

Das sind doch alles Implementations-Details, die durch schöne Browser-APIs wie FormData von uns abgekapselt werden. Der Browser kümmert sich alleine darum, die Daten in eine HTTP-konforme Form zu bringen. Genau wie der WebServer sich um die empfangenen Daten kümmert und für den Web-Entwickler wieder aufbereitet.

Was hierbei die Content-Types betrifft: Die werden selbstverständlich auch übertragen, die liefert schon der Browser. Wenn ich die serverseitig brauche, greife ich nur in den Hash, den nicht ein Parser liefert sondern ein Serializer (nur andersrum) und dieser Hash sieht dem Javascript-Objekt täuschend ähnlich, aber sowas von :)

Tut mir leid, ich kann den Vorteil immer noch nicht erkennen. Im Gegenteil ich halte das sogar für schlechtes Software-Design. Du entscheidest dich bewusst gegen die Standard-Direktive von HTTP um den Content-Type zu übertragen. Stattdessen überträgst du eine Hashmap an den Server. Server und Client müssen also wissen wie diese Hashmap aufgebaut ist. Dieses gemeinsame Wissen, um die Hashmap, lässt sich als Protokoll interpretieren. Solange Server und Client dieses Protokoll sprechen ist das alles schön und gut. Einen qualitativen Mehrwert bietet dein Protkoll, gegenüber HTTP aber nicht. Du beschneidest erst das Potenzial von HTTP und baust es dann wieder nach.  Du replizierst damit also nur wieder das Verhalten von HTTP, du entwickelst eine innere Platform, das ist ein bekanntest Anti-Pattern, auch wenn die Ausmaße sich in deinem Fall in bescheidenen Grenzen halten. Wenn dir als nächstes aber der Gedanke kommen sollte die HTTP-Verben POST, GET usw. zu ersetzen, dann solltest du dich spätestens daran erinnern ;) Das Hauptproblem damit ist, dass deine Anwendung nicht mehr in der Lage ist mit jedem anderen herkömmlichen WebServer zu reden, weil sie dein Protokoll nicht sprechen. Mal als Beispiel: Wenn du die Daten so an einen Apache mit PHP sendest, landen die Dateien nicht erwartungsgemäß im $_FILES-Array. Der PHP-Entwickler müsste also auch erstmal dein Protokoll implementieren. Natürlich fällt immer Arbeit an, wenn ein System in ein anderes System migriert werden muss, aber in diesem Fall ließe sich das vermeiden.

und dieser Hash sieht dem Javascript-Objekt täuschend ähnlich, aber sowas von :)

Ich finde dieser Hash sollte nur die Daten halten, und keine Informationen darüber wie diese Daten interpretiert werden sollen. Letzeres sollte auf einer niedrigeren Protokollschicht geschehen, dann sind diese Aspekte sauber entkoppelt.

Die eigentlichen Daten (wenn es keine Binärdaten sind) würde ich auch nicht als Blob (der Name kommt nich von ungefähr) versenden, da würde ich zu JSON greifen, das ist menschenlesbar, maschinenlesbar, im Web zu Hause und wohl auch der zukunftsträchtigste Kandidat.

CouchDB ist für mich eine große Inspiration beim Entwurf von klar strukturierten HTTP-Schnittstellen.