nicht angemeldet
Tach!
Eine kleine Anmerkung zu diesem Request: Ein POST-Request mit GET-Parametern ist nicht gerade eine zweckmäßige Empfehlung, ein Request erfolgt mit einer Methode.
Die Bezeichnung GET-Parameter kommt wohl aus dem PHP-Umfeld und allen anderen Systemen, die den Querystring aus dem Request auf eine Struktur mit GET im Namen abbilden. Ansonsten ist er einfach nur ein Querystring, der zu einer URL gehört. Und das ganz unabhängig davon, mit welcher Methode diese an einen Server gesendet wird.
Des Weiteren ist es reichlich ungeschickt, einen API-Key, den nicht jeder gleich sehen soll, im URI als GET-Parameter unterzubringen.
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? Nimmt man da lieber eine hotti-Spezial-Lösung oder hängt ihn einfach an den Querystring an? Obendrein wird es für einen Türsteher-Server einfacher sein, den Key aus dem Querystring zu nehmen, als ein JSON/XML/wasauchimmer-Datenpaket aufzudröseln.
Der für den Request programmierte Content-Type: application/json passt außerdem besser zur Requestmethode PUT anstelle POST.
Für die Anwendung "gib mir Daten zu den Daten, die ich dir sende" passt PUT nicht wirklich, denn das ist zum Übertragen von Daten(sätzen) zwecks Speicherung vorgesehen. ("The PUT method requests that the enclosed entity be stored under the supplied Request-URI." RFC 2616)
Zumal der Request mit SSL erfolgt, in diesem Fall wird der API-Key gleich mit verschlüsselt.
Du meinst also, dass die URL bei einer HTTPS-Verbindung unverschlüsselt übertragen wird? Dann solltest du mal dein Wissen auffrischen. Es ist nicht so, dass die HTTP-Header im Klartext und der Body verschlüsselt übertragen werden. Lediglich der Hostname wird mit dem SNI-Zusatz zum TLS schon während des Handshake-Prozesses übertragen, damit man mehrere eigenständige (und damit mit separaten Zertifikaten und Schlüsselgedöns ausgestattete) VHosts auf derselben IP-Adresse betreiben kann. Alles andere geht verschlüsselt auf die Reise, inklusive Header und URL. Dass du bei dir im Browser quasi Quellen-TKÜ machst und die Requests unverschlüsselt sehen kannst, steht auf einem anderen Blatt.
dedlfix.
Robert R.