GraphQL-zu-XML-Konverter
GraphQL-Schema oder Query einfügen. Sauberes XML bekommen.
Was dieses Tool macht
Wer schon mal eine GraphQL-API für ein Team dokumentieren musste, das nur mit XML arbeitet, oder ein GraphQL-Schema an einen Legacy-SOAP-Client anschließen sollte, kennt die unangenehme Seite: GraphQL-Typen lassen sich nicht eins zu eins übersetzen. Schema oder Query hier einfügen und wohlgeformtes XML in einem Durchgang zurückbekommen. Ob eine Handvoll type-Definitionen, eine vollständige SDL-Datei oder eine konkrete Query mit Argumenten — das Ergebnis ist dasselbe: ein vollständiges XML-Dokument, das die Form der Daten spiegelt.
Der Konverter kennt die GraphQL-Spezifikation, nicht nur die Oberflächensyntax. Die Scalar-Defaults fallen so aus, wie man es erwartet — String wird Text, Int und Float werden numerischer Text, Boolean wird true/false und ID wird ein String-Wert. Non-Null-Marker (String!) und List-Marker ([OrderItem!]!) werden berücksichtigt: Eine verpflichtende Liste erscheint als Container-Element mit einem Kind pro Item, und nullable Felder ohne Wert kommen als leere Elemente durch, damit die Form des Dokuments stabil bleibt.
Über die eingebauten Typen hinaus deckt das Tool auch den Rest des Typsystems ab. input-Typen werden zu verschachtelten Elementen, enum-Werte kommen als String-Text durch, interface- und union-Typen werden in ihre konkreten Formen aufgelöst und Fragmente (benannt oder inline) werden eingezogen, sodass die Ausgabe flach und eigenständig ist. Custom-Scalars wie DateTime, Date und JSON werden als ISO-8601 oder stringifizierte Werte ausgegeben. Wenn du eine query mit Argumenten einfügst, werden die Argumente als Teil des Wurzelelements erhalten, sodass das XML eine treue Aufzeichnung des Requests ist und nicht bloß ein Datenhaufen.
So geht's
Drei Schritte. Funktioniert gleich, egal ob du einen einzelnen Typ einfügst oder ein komplettes Schema mit Queries.
GraphQL einfügen (oder das Beispiel probieren)
Das GraphQL wie es ist in den linken Editor werfen. Ein einzelner type, eine vollständige SDL-Datei mit input/enum/interface/union oder eine konkrete Query mit Variablen — alles okay. Klick auf Beispiel laden, wenn du erst mit einer realistischen Form rumspielen willst.
Du musst weder Kommentare entfernen noch die SDL-Syntax umformatieren. Lass es so, wie dein Editor es geschrieben hat — triple-quoted Docstrings und Raute-Kommentare passen beide.
Konvertieren klicken
Klick auf den grünen Konvertieren-Button. Das Tool liest das Schema (oder die Query), löst Fragmente und List-/Non-Null-Marker auf und baut das XML in einem Durchgang. Während der Konvertierung läuft ein kurzer Ladeindikator.
XML kopieren
Das rechte Panel füllt sich mit eingerücktem, wohlgeformtem XML, das jeder standardkonforme XML-Parser akzeptiert. Direkt in deinen SOAP-Request, in die Doku, als Fixture oder XSD-Beispiel rüberkopieren.
Wann das wirklich nützlich ist
XML-basierte Doku für eine GraphQL-API
Interne Doku oder Partnerdokumentation, die in XML lebt (DITA, DocBook, XSD-gestützte Referenz). Schema einfügen, Beispiel-XML-Payloads bekommen, die zu den echten Typen passen — kein Handübersetzen.
XML-Fixtures aus einem Schema erzeugen
Contract-Tests, Snapshot-Tests oder ein Mock-Server, der XML spricht. Gib ihm das Schema, das du schon hast, und bekomme konsistente Fixture-XML mit jeder Liste, jedem nullable-Feld und jedem verschachtelten Typ an der richtigen Stelle.
Brücke zu Legacy-SOAP-Clients
Ein Partnersystem akzeptiert nur XML-Payloads, dein Backend spricht aber GraphQL. Query und Response-Typ einfügen und einen XML-Body als Ausgangspunkt bekommen, den du in den SOAP-Request setzen kannst.
Schema-Migration & Analyse
Weg von GraphQL hin zu einer XML-basierten API (oder einfach die zwei Formen vergleichen). Hol dir eine Side-by-Side-XML-Version jedes Typs, damit Reviewer, die kein SDL lesen, folgen können.
Häufige Fragen
Wie werden type, input, enum, interface und union behandelt?
type und input werden zu Container-Elementen mit einem Kind pro Feld. enum-Werte kommen als einfacher String-Text durch (der Enum-Name in Großbuchstaben, genau wie im SDL deklariert). interface löst sich in ihre Felder plus die Felder des implementierenden Typs auf, sobald wir den konkreten Typ kennen. union löst sich in die Form des passenden Mitglieds auf. Die vollständigen Regeln stehen in der GraphQL-Type-Language-Referenz.
Welche Defaults gelten für String, Int, Float, Boolean und ID?
String und ID werden Textinhalt. Int ist eine einfache Ganzzahl. Float ist eine Dezimalzahl ohne nachlaufende Nullen. Boolean ist der kleingeschriebene Text true oder false. Das passt zu den Scalar-Definitionen in der GraphQL-Spec, sodass die Ausgabe sauber durch einen XML-Parser läuft.
Wie werden Non-Null- (!) und List-Marker ([T]) gehandhabt?
Non-Null (String!) wird als Feld behandelt, das erscheinen muss — nullable Felder ohne Wert kommen als leere Elemente durch, damit die Form des Dokuments vorhersagbar bleibt. Listen ([OrderItem!]!) werden zu einem Container-Element mit einem Kind pro Item, benannt nach dem Elementtyp — z. B. items: [OrderItem!]! wird zu <items><OrderItem/><OrderItem/></items>. Verschachtelte Listen ([[Int]]) verschachteln sich genauso.
Werden Fragmente aufgelöst?
Ja. Benannte Fragmente (...OrderFields) und Inline-Fragmente (... on Order { ... }) werden inline aufgelöst, damit das XML flach und eigenständig ist. Du musst die Fragment-Definitionen nicht separat einfügen — wenn sie im gleichen Block stehen, verdrahtet das Tool sie. Das passt zum normalen Query-Execution-Modell, bei dem Fragmente ins Selection-Set ausgebreitet werden, bevor die Response gebaut wird.
Was ist mit Custom-Scalars wie DateTime?
Gängige Custom-Scalars (DateTime, Date, Time, UUID, JSON) werden per Konvention als ISO-8601-Text oder stringifizierte Werte ausgegeben — wie die meisten Scalar-Libraries es machen. Unbekannte Custom-Scalars fallen auf String-Text zurück, damit nichts stillschweigend verschwindet. Falls du ein bestimmtes Format brauchst, nachbearbeite das XML oder benenne den Scalar um.
Kann ich eine Query mit Argumenten einfügen, nicht nur ein Schema?
Ja. Füge eine query mit Variablen und Argumenten ein — z. B. query GetOrder($orderId: ID!) { order(id: $orderId) { ... } } — und die Argumente kommen als Attribute am Wurzelelement durch. Die ausgewählten Felder bestimmen, welche Teile der Response-Form serialisiert werden, sodass das XML dem entspricht, was die Query tatsächlich liefern würde, nicht dem ganzen Typ.
Weitere Tools, die du brauchen könntest
GraphQL zu XML ist nur ein Puzzlestück. Diese Tools passen gut dazu: