JSON-Objekt in Query-String umwandeln

APIs, Front-End-Router und Analyse-Pipelines speichern Filter und Formularfelder oft als einfache JSON-Map und brauchen dennoch einen korrekt kodierten Query-String für die Adresszeile oder einen ausgehenden HTTP-Client. Diese Fähigkeit akzeptiert ein flaches JSON-Objekt, wandelt jeden skalaren Wert in Text um, percent-kodiert jeden Schlüssel und Wert und liefert den anhängbereiten Query-String zusammen mit geordneten Paaren und einer normalisierten String-Map. Verschachtelte Objekte und Arrays werden mit invalid_input abgelehnt, damit Aufrufer keinen halbstrukturierten Müll emittieren, der wie eine gültige URL aussieht.

Vom flachen Objekt zum kodierten Query-String

Ein URL-Query-String ist eine Folge von Name-gleich-Wert-Feldern, verbunden durch Ampersands, optional mit einem Fragezeichen nach dem Pfad. Verschachtelte Objekte und Arrays sind absichtlich nicht unterstützt: ein Query-Parameter ist ein flaches Schlüssel-Wert-Paar, und das Serialisieren verschachtelter Struktur in einen einzigen opaken String würde Fehler verbergen, die Aufrufer meist beheben wollen, bevor die Anfrage den Client verlässt. Leere Objekte erzeugen einen leeren Query-String und die Form nur mit Fragezeichen-Präfix, nützlich für Tests, die keine Parameter behaupten statt einen Dummy-Schlüssel zu erfinden. Längenlimits für Schlüsselanzahl und serialisierte Gesamtgröße halten pathologische Maps davon ab, im kostenlosen Browser-Pfad Speicher zu erschöpfen. Wenn Ihre Quelle der Wahrheit bereits ein JSON-Objekt ist —zum Beispiel ein Filterzustand, ein Formularmodell oder eine Konfigurationsmap— brauchen Sie einen deterministischen Weg, diese Map in das Drahtformat zu überführen, das Browser und Server erwarten. Diese Fähigkeit läuft die eigenen Schlüssel des Objekts in Einfügereihenfolge ab, wandelt jeden skalaren Wert in einen stabilen String um (Booleans werden true oder false, endliche Zahlen nutzen gewöhnliche Dezimalnotation, null wird ein leerer Wert) und wendet encodeURIComponent auf jeden Schlüssel und jeden Wert an, sodass Leerzeichen zu percent-twenty, Ampersands zu percent-twenty-six werden und Unicode den Transit übersteht. Das Ergebnis ist ein Query-String, ohne aus rohen Sonderzeichen zusätzliche Trenner zu erfinden. Weil der Pfad reine String- und Objektarbeit ohne Netzwerk, ohne Zufalls-Seeds und ohne Wanduhr ist, erzeugen identische Eingaben stets identisches JSON. Der API-Preis bei Erfolg ist die veröffentlichte Basis von $0.002 pro Element, und Validierungsfehler belasten den vorausbezahlten KIT-Saldo nicht.

Eingabevertrag, Antwortform und Fehlerverhalten

Der Wert muss ein flaches Objekt sein, dessen Eigenschaften Strings, Zahlen, Booleans oder null sind. Nicht-endliche Zahlen (NaN und Infinity) werden abgelehnt, weil sie in Query-Strings keine standardisierte portable Form haben. Beispiel: name Ada Lovelace, city London, active true und score zweiundvierzig erzeugen einen Vier-Parameter-String mit percent-kodierten Leerzeichen und reservierten Zeichen. Senden Sie per POST einen JSON-Body mit dem Pflichtfeld object (Aliase json, data, params, map, fields). Sie können object auch als JSON-Text übergeben, der zu einer solchen Map parst. Arrays auf der obersten Ebene, null, Skalare und jeder verschachtelte Objekt- oder Array-Wert scheitern mit invalid_input und einer klaren englischen Meldung, die bei Bedarf den fehlerhaften Schlüssel nennt. Bei Erfolg enthält die Antwort query (den kodierten String ohne führendes Fragezeichen), query_with_prefix (denselben mit führendem Fragezeichen, oder nur das Fragezeichen wenn keine Schlüssel), count (die Parameteranzahl), pairs (ein geordnetes Array aus key- und value-Strings nach skalarer Koercion und vor der Kodierung) sowie object (eine last-wins-String-Map dieser koerzierten Werte). Klassischer Fehler: verschachtelte Filter unter einem Schlüssel filter gleich einem Objekt senden und invalid_input statt einer still kaputten URL erhalten. Der API-Preis bei Erfolg ist die veröffentlichte Basis von $0.002 pro Element; Validierungsfehler werden nicht berechnet.

Wo JSON-zu-Query-Umwandlung sich rechnet

Curriculum-Autoren für Web-Grundlagen wollen eine eigene Landing für Objekt-zu-Query-Serialisierung, statt das Thema unter einem bidirektionalen Parser zu vergraben, weil die Suchintention anders ist: wer eine JSON-Map hält, will Kodierung, keine Parse-Modus-Optionen. Weil die Implementierung reines Parse-Tier A ist, kostet jeder erfolgreiche Aufruf den veröffentlichten Basispreis $0.002 ohne Modell-Tokens und ohne ausgehendes Netzwerk.