navigator.geolocation.getCurrentPosition()

[1UnitedPower]

Hakuna matata!

Ich würde die Frage eher andersherum stellen: Warum ein POST-Request an einem URL mit Query_String?

Eine REST-API besteht im Allgemeinen aus vielen Anfragemöglichkeiten, die nicht alle nur auf POST basieren, zumindest auch die GET-Methode wird wohl von den meisten APIs rege genutzt. GET-Anfragen haben allerdings keinen Body, deshalb ist es auch nicht möglich dort den API-Key zu übertragen. In diesem Fall müsste man den API-Key also anderorts kodieren. Dies ginge in einem Cookie oder in einem benutzerdefinierten Header, oder eben im Querystring der URL. Jetzt hat man blöderweise den Fall, dass der API-Key bei POST-Anfragen im Body übertragen wird und bei GET-Anfragen im Header oder in der URL. Das erfordert schon zwei verschiedene Lösungen für das selbe Problem. Da sollten dann die Alarmglocken angehen.

Wer sowas serverseitig verarbeiten will, muss den Parser seiner PL schon sehr genau kennen, die arbeiten nämlich unterschiedlich von PL zu PL.

PL? Programming-Language? Man muss nicht den JavaScript-Parser der V8-Engine kennen, wenn man eine REST-Schnittstelle nutzen möchte. Ebenso wenig muss man den PHP-Parser der Zend-Engeine kennen.

Du meinst vermutlich, dass man die Schnittstellen des URL-Parsers bzw. des HTTP-Body-Parsers kennen muss. Diese Sache wird einem heutzutage von modernen Web-Frameworks allerdings schon abgenommen und man erhält über eine vereinfachte Schnittstelle Zugriff auf die Anfrage-Parameter. In PHP folgen die bekanntesten Frameworks zum Beispiel diesem Muster.

Und ja, die Hotti-Speziallösung: Einen JSON musst Du auftrödeln, wenn da noch was rein soll.

Wenn man die Daten erst unmittelbar vor der Übetragung kodiert, ergibt sich dieses Problem erst gar nicht. Über streamable JSON habe dich ja auch schon mal unterrichtet, damals ging es zwar um Dekodierer, aber den Weg gibt es auch für die Umkehrrichtung, dem Kodierer.