nicht angemeldet
hi,
Der Request einer Anwendung wird in den meisten Fällen für den Anwender unsichtbar gesendet. Du musstest dich auch erst in die Niederungen der Entwicklertools begeben, um ihn zu sehen. Und ob er da in der Kopfzeile des Requests zu sehen ist oder erst einen Klick später in den POST-Daten zu sehen ist, spielt dann auch keine Rolle mehr. Zudem wird wohl der Request-Body einem gewissen Standard folgen, der die Übermittlung eines Google-spezifischen API-Keys nicht vorgesehen haben wird. Wie sollen da noch Extra-Daten eingearbeitet werden?
Guck Dir den Enctype multipart/form-data an. Der API-Key wäre ein Parameter, der JSON wäre ein Parameter. Multipart: Jeder Part kann einen eigenständigen Content-Type haben. Der JSON-Part kriegt außerdem den Parameter filename='blob' denn das ist ja nichts weiter als eine Datei.
Ein solcher POST schafft klare Verhältnisse und serverseitig gibt es entsprechende Libs für alle PLs die überhaupt serverseitig eingesetzt werden.
Ich würde die Frage eher andersherum stellen: Warum ein POST-Request an einem URL mit Query_String? Wer sowas serverseitig verarbeiten will, muss den Parser seiner PL schon sehr genau kennen, die arbeiten nämlich unterschiedlich von PL zu PL. Aber die Kollegen dürfen gerne weiter pfuschen, vielleicht gibt es demnächst ein Update für LiveHTTPHeaders und vieleicht sorgen die auch dafür, dass bestimmte URLs mit bestimmten Query_Strings nicht in places.sqlite landen. Das sind alles Abhängigkeiten, die keine Rolle spielen würden mit Standards, die sich jahrelang bewährt haben.
Und ja, die Hotti-Speziallösung: Einen JSON musst Du auftrödeln, wenn da noch was rein soll. An eine mit meinem Algorithmus serialisierte Binärsequenz kannst Du es einfach anhängen oder am Anfang einfügen. Ebenfalls seit Jahren bewährt ;)
MfG