Auch ich nix OData kennen...

Menschen lesen Sequenzen anders als Maschinen.
Menschenlesbar
Maschinenlesbar

Für den 2. Link habe ich lediglich den Content-Type: text/plain gesetzt, damit der Browser die Binary zeigen kann. Der 1. Link zeigt dieselbe Binary als Dump.

Du vergisst zu erwähnen, dass "Dein Binary" im zweiten Link nicht nur einen anderen Content-Type hat, sondern auch durch etwas magisches auf Deiner Seite gelaufen ist und danach durch Data::Dumper gejagt wurde.

Nein, kein Data::Dumper. Der 2. Link serialisiert einfach nur die serverseitig im Hauptspeicher liegende Routing-Table. Der Content-Type ist für den BOT absolut uninteressant. Ich könnte genausogut application/octet-stream senden oder foo/bar.

Ein BOT schnappt sich die Binary in Bruchteilen von Sekunden und kann unmittelbar mit dem Empfang der ersten Bytes mit der Verarbeitung beginnen (z.B. HEAD-Requests auf jeden URL feuern).

Bei wirklich großen Datenmengen kann eine sequentielle Verarbeitung sinnvoll sein, ja. Das bedeutet noch lange nicht, dass das innerhalb des Austauschsformats passieren muss.

Beachte den Dateibegriff nach Niklaus Wirth: Dateien sind Sequenzen. Abstrakt: Alles was den Hauptspeicher verlassen soll, egal ob in eine Datei, ein PIPE, STDOUT, ein Socket (HTTP)... ist eine Byte-Sequenz. Sequenzen werden sequentiell erzeugt und sequentiell gelesen. Sequenzen enthalten Datenstrukturen, ein bestimmter Serialize-Algorithmus vermittelt zwischen einer Sequenz und der im Hauptspeicher vorliegenden Datenstruktur (Array, Hash, Refereenzen, Zeiger).

Das bedeutet, dass ein wahlfreier Zugriff (Random Access) nicht etwa in einer Sequenz abgebildet ist, sondern einzig über den Hauptspeicher erfolgt.

N. Wirth um 1980. Letztendlich sind XML und JSON auch nur gewöhnliche Sequenzen.

Einen Dump (ähnlich JSON) muss eine Maschine komplett in den Hautpspeicher laden, damit er geparst werden kann (gilt auch für XML).

Skizzier mal bitte Dein Szenario an einem konkreten Beispiel(ohne Bilder/Audio, siehe unten), Dein Dump umfasst aktuell ~ 6 Kilobyte. Bei 600 Kilobyte könnte man ansatzweise über einen Vorteil nachdenken.

Der Dump dient nur einer bildlichen Veranschaulichung. Er weist jedoch dem Programmierer den Weg für den wahlfreien Zugriff in den Hauptspeicher: $body = $bin->{'/index.html'}{body}.

Eingepackt hat meine $bin eine Größe von 1.3MB als XML verpackt wäre sie wesentlich größer. Der Dump zeigt jedoch nicht alle Attribute.

Bei jedem Aufruf wird massiver Overhead übertragen, denn ich gar nicht möchte / brauche. Wenn Du mir stattdessen einen Link und eine Prüfsümme für tatsächliche Binärdaten übertragen würdest, könnte ich auf meiner Seite überprüfen, ob ich diese überhaupt neu laden muss.

Webservice: Der Request wird spezialisiert unter Einbeziehung der Request-Method und ggf. der im Request enthaltenen Parameter.

Ein proprietärer Standard könnte z.B. festlegen, dass grundsätzlich nur ein PUT-Request erfolgt und einzig die aus der gesendeten Sequenz erzeugte Datenstruktur darüber entscheidet, welche Aktionen serverseitig auszuführen sind. Auf diese Art und Weise funktioniert mein Content-Management, ich sende eine Datei an meinen Webservice, darin liegt z.B. alles, was eine Response auf /index.html braucht. Mein Webservice baut dann die index.html samt Body u.a. Attribute in die Binary ein. Das ganze wird über den Hauptspeicher abgewickelt und im DESTROY wird die $bin aus dem Hauptspeicher zurück auf die Festplatte geschrieben.

Demo:
D:>lwp-request -m PUT http://rolfrost.de/binf.html
Please enter content (text/plain) to be PUTed:
asdf123 foo bar
^Z
PUTDATA:
asdf123 foo bar

[...] Beim Publizieren einer Seite mit eingebauten Bildern, werden letztere gleich mit übertragen. Mit XML oder JSON ist sowas nicht zu machen.

Klar geht das: Base64. Man kann frei entscheiden, ob man den Overhead möchte oder lieber eine Lösung wie oben skizziert verfolgt.

Achja, die gute alte ASCII-Welt. Der ganze MIME-Standard ist sowas von Schrott und da bin ich nicht der Einzige der so denkt ;)