<p>httpie Ändern der Reihenfolge der JSON-Felder in der Ausgabe</p>

Erstellt am 14. Jan. 2016  ·  27Kommentare  ·  Quelle: httpie/httpie

Sie fragen sich, wie ich httpie zwingen kann, die Reihenfolge der json-Felder nicht zu ändern?

curl -i http://localhost:8080/v1/notes/569766aed4c661fba8d85a12

{
  "id": "569766aed4c661fba8d85a12",
  "content": "hi"
}

mit httpie

http get :8080/v1/notes/569766aed4c661fba8d85a12 

{
  "content": "hi",
  "id": "569766aed4c661fba8d85a12"
}

Ich bevorzuge, dass das Feld id immer das erste ist. Irgendwelche Gedanken?

Hilfreichster Kommentar

Ich habe einfach viel mehr Zeit verloren, als ich zugeben möchte, als ich versuchte, ein Problem in meiner serverseitigen JSON-Bibliothek aufzuspüren, weil ich nicht herausfinden konnte, warum die Daten in der falschen Reihenfolge gesendet wurden. Es kam mir nicht einmal in den Sinn, dass der Kunde Sachen nachbestellen könnte.

Lohnt es sich überhaupt, JSON nachbestellen zu können? In 90 % der Fälle wird es die Serverausgabe eher verschleiern als verbessern.

Ich würde eine Pull-Anfrage senden, aber es würde nur ein "True" in ein "False" in einer Datei ändern.

Alle 27 Kommentare

Beachten Sie, dass im json-Formatierer sort_keys=True
Man kann davon ausgehen, dass dies der Grund ist

ah okay, danke.

Mit folgendem konnte ich das Sortieren der Schlüssel deaktivieren (leider zusammen mit der Einrückung, aber das ist kein so großes Problem)

http --pretty=colors get :8080/v1/notes/569766aed4c661fba8d85a12

Gern geschehen, obwohl ich das Gefühl habe, dass dies die Frage aufwirft, ob die Sortierung etwas ist, das allgemein durchgeführt werden sollte, oder ob es so sein sollte, wie es vom Server beabsichtigt ist

Wäre es möglich, einen anderen Wert für --pretty einzuführen, um Farben und Formatierungen zuzulassen, aber ohne die Schlüssel in der Antwort zu sortieren?

könnten Sie unsortiert als Standard festlegen? und eine Option wie --sort-keys für Leute, die das Verhalten der Sortierschlüssel wollen; siehe https://bugs.python.org/issue21650 das json.tool hat bereits eine Option in python3

➸ python3 -m json.tool -h
usage: python -m json.tool [-h] [--sort-keys] [infile] [outfile]

A simple command line interface for json module to validate and pretty-print
JSON objects.

positional arguments:
  infile       a JSON file to be validated or pretty-printed
  outfile      write the output of infile to outfile

optional arguments:
  -h, --help   show this help message and exit
  --sort-keys  sort the output of dictionaries alphabetically by key

Ich habe einfach viel mehr Zeit verloren, als ich zugeben möchte, als ich versuchte, ein Problem in meiner serverseitigen JSON-Bibliothek aufzuspüren, weil ich nicht herausfinden konnte, warum die Daten in der falschen Reihenfolge gesendet wurden. Es kam mir nicht einmal in den Sinn, dass der Kunde Sachen nachbestellen könnte.

Lohnt es sich überhaupt, JSON nachbestellen zu können? In 90 % der Fälle wird es die Serverausgabe eher verschleiern als verbessern.

Ich würde eine Pull-Anfrage senden, aber es würde nur ein "True" in ein "False" in einer Datei ändern.

stimme @carlfish voll und ganz zu

@jkbrzt irgendwelche Gedanken dazu?

Ich habe dies lokal getestet, und es sieht so aus, als ob Sie, wenn Sie dem Formatierer sagen, er solle nicht alphabetisieren, stattdessen Objektschlüssel in einer willkürlichen Reihenfolge erhalten - ich denke, es wird von einem ungeordneten Wörterbuch unterstützt? In diesem Fall ist Alphabetisierung wahrscheinlich besser als zufällig.

Ich denke, es wird von einem ungeordneten Wörterbuch unterstützt?

Ja, die Python json.loads wird standardmäßig in ein Diktat geladen, was eine unvorhersehbare Reihenfolge ist (etwas intern verwendeter Hash-Code), das ist nicht besser als eine alphabetische Reihenfolge;

aber es gibt eine Problemumgehung, bitte verwenden Sie object_pairs_hook=OrderedDict ; und lassen Sie sort_keys fallen, wenn Sie json.dumps anrufen

>>> import json
>>> from collections import OrderedDict
>>> data = json.loads('{"foo":1, "bar": 2}', object_pairs_hook=OrderedDict)
>>> print json.dumps(data, indent=4)
{
    "foo": 1,
    "bar": 2
}
>>> 

Zwei rasierte Yaks später: Pull Request -> https://github.com/jkbrzt/httpie/pull/520

Für das, was es wert ist, bin ich zufällig ein Benutzer, der die Schlüssel in meiner JSON-Ausgabe gerne sortiert sieht. Mein Server definiert keine Reihenfolge, in der er die Schlüssel ausgibt, und wenn ich nachsehen möchte, ob der erwartete Schlüssel im JSON-Text enthalten war oder nicht, ist es viel einfacher, wenn sie sortiert sind. Ich würde also sagen, die Sortierfunktion nicht einfach willkürlich zu entfernen, sondern sie per Flag konfigurierbar oder umschaltbar zu machen.

Ping-Autor @jakubroztocil ist dies außerhalb der Wartung?

Gibt es eine Traktion zu diesem Thema? Wie @carlfish habe ich gerade peinlich viel Zeit damit verbracht, einen Fehler in meinem Server zu beheben, nur um herauszufinden, dass httpie das Problem war.

Es scheint sehr unintuitiv, dass Daten vom Server neu geordnet/sortiert werden, ohne dass der Benutzer dies ausdrücklich aktiviert.

Es gibt eine Lösung in PR #520, die leider noch nicht zusammengeführt wurde.

Das wäre wirklich nützlich. Sortieren ist nicht so gut, wenn man es nicht will.

das ganze Python2 veraltet; kann ein Betreuer einen Blick auf die ausstehenden PRs werfen? Aus den Grafiken der Mitwirkenden geht hervor, dass @jakubroztocil @msabramo noch aktiv ist?

Arbeitet jemand daran? Können wir erwarten, dass dies gelöst wird?

@opensas weiß nichts davon, aber eine mögliche Lösung ist die Verwendung des Tools jq :

http https://jsonplaceholder.typicode.com/todos/1 | jq -C

@opensas diese Funktion wird in der kommenden Version 2.2.0 enthalten sein.


Eine mögliche Lösung ist die Verwendung des Tools jq :

http https://jsonplaceholder.typicode.com/todos/1 | jq -C

@nmtitov hier ist es nicht wirklich jq , das die Reihenfolge wiederherstellt, sondern die Umleitung der Ausgabe , die Farben und Formatierung deaktiviert (effektiv --pretty=none setzt).

vielen Dank für den Tipp, ist mir in diesem Thread schon aufgefallen.
Gibt es eine Möglichkeit, den Rest der Anfrageinformationen (Status und Header) zu behalten, nachdem ich durch jq geleitet wurde?

Ich meine, httpie gibt das zurück:

HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 109
Content-Type: application/json; charset=utf-8
Date: Sat, 25 Apr 2020 11:14:32 GMT
ETag: W/"6d-wWZh31xOzPgYyzU23ihgZaW8KkI"
Strict-Transport-Security: max-age=15552000; includeSubDomains
X-Content-Type-Options: nosniff
X-DNS-Prefetch-Control: off
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block

[
    {
        "id": 1,
        "text": "Read the docs"
    },
    {
        "id": 2,
        "text": "Create my first application"
    },
    {
        "id": 3,
        "text": "Write tests"
    }
]

aber http | jq -C entfernt den ersten Teil und gibt nur zurück:

[
  {
    "id": 1,
    "text": "Read the docs"
  },
  {
    "id": 2,
    "text": "Create my first application"
  },
  {
    "id": 3,
    "text": "Write tests"
  }
]

@opensas Ich glaube nicht, dass es möglich ist, es sei denn, Sie schreiben Ihren benutzerdefinierten Bash-Wrapper

@opensas @nmtitov Das Weiterleiten der Ausgabe hat den Nebeneffekt, dass der Standardwert --print=hb (Kopfzeilen und Textkörper drucken) in --print=b geändert wird (nur den Textkörper drucken, da dies normalerweise das ist, was Sie beim Umleiten der Ausgabe wünschen ). Sie können explizit verlangen, dass die Header mit --print=hb werden.

https://httpie.org/docs#output-options

@jakubroztocil dies wird nicht funktionieren, da jq JSON-Text als Eingabe erwartet

$ http --print=hb https://jsonplaceholder.typicode.com/todos/1 | jq -C
parse error: Invalid numeric literal at line 1, column 9

Ich verstehe. Sie könnten http --download httpbin.org/get | jq verwenden

Ich habe die folgende Workqround gefunden, anstatt httpie zu verwenden, habe ich curlie gefunden, was anscheinend so ist

Wie curl, aber im Gegensatz zu httpie, werden Header auf stderr statt auf stdout geschrieben.

Also ich kann es so verwenden:

$ curlie GET localhost:3000/tasks | jq -C
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 304
ETag: W/"130-ED1W4hQo1i7na7wy5Ewc7iKdoJc"
Date: Wed, 27 May 2020 06:28:26 GMT
Connection: keep-alive

[
  {
    "id": 2,
    "title": "new task2",
    "description": "description2",
    "status": "OPEN"
  },
  {
    "id": 3,
    "title": "new task3",
    "description": "description3",
    "status": "OPEN"
  }
]

Wobei ich wie bei httpie die Header hätte

Übrigens habe ich dieses praktische Skript erstellt:

$ cat ~/bin/c
curlie "$@" | jq -C

Gerade veröffentlichte Version 2.2.0, die dieses Problem behebt. Erfahren Sie hier mehr über die neuen --unsorted , --sorted und --format-options :

https://httpie.org/docs#colors -and-formatting

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

hrj picture hrj  ·  5Kommentare

loretoparisi picture loretoparisi  ·  6Kommentare

jclem picture jclem  ·  6Kommentare

a-x- picture a-x-  ·  7Kommentare

Govinda-Fichtner picture Govinda-Fichtner  ·  6Kommentare