GraphQL till XML-omvandlare
Klistra in ett GraphQL-schema eller en fråga. Få tillbaka ren XML.
Vad verktyget gör
Har du någonsin behövt dokumentera ett GraphQL-API för ett team som bara jobbar i XML, eller koppla ett GraphQL-schema mot en gammal SOAP-klient, vet du var skon klämmer: GraphQL-typer översätts inte ett-till-ett. Klistra in ditt schema eller din fråga här och få välformad XML i en enda körning. En handfull type-definitioner, en hel SDL-fil eller en konkret fråga med argument — samma resultat: ett komplett XML-dokument som speglar datans form.
Omvandlaren kan GraphQL-specifikationen, inte bara ytsyntaxen. Skalärernas standardvärden landar som man kan förvänta — String blir text, Int och Float blir numerisk text, Boolean blir true/false och ID blir ett strängvärde. Non-null-markörer (String!) och list-markörer ([OrderItem!]!) respekteras: en obligatorisk lista dyker upp som ett container-element med ett barn per objekt, och nullable-fält utan värde kommer igenom som tomma element så att dokumentets form förblir konsekvent.
Utöver de inbyggda typerna hanterar verktyget också resten av typsystemet. input-typer blir nästlade element, enum-värden kommer igenom som strängtext, interface- och union-typer löses upp mot sina konkreta underliggande former, och fragment (namngivna eller inline) bakas in så utdatan är platt och självförsörjande. Egna skalärer som DateTime, Date och JSON skrivs ut som ISO-8601 eller strängifierade värden. Klistrar du in en query med argument sparas argumenten som en del av rotelementet, så XML:en blir en trogen återgivning av förfrågan, inte bara en dataklump.
Så här använder du det
Tre steg. Fungerar likadant oavsett om du klistrar in en enda typ eller ett helt schema med frågor.
Klistra in din GraphQL (eller testa exemplet)
Släpp GraphQL-koden rakt av i vänstra editorn. En enstaka type, en komplett SDL-fil med input/enum/interface/union, eller en konkret fråga med variabler — allt funkar. Tryck på Ladda exempel om du vill börja med en realistisk form.
Du behöver inte ta bort kommentarer eller omformatera SDL-syntaxen. Låt det ligga som editorn skrev det — både trippelciterade docstrings och hash-kommentarer går bra.
Tryck på Konvertera
Klicka på den gröna Konvertera-knappen. Verktyget läser schemat (eller frågan), löser upp fragment och list-/non-null-markörer och bygger XML:en i ett svep. En kort laddningsindikator syns medan konverteringen pågår.
Kopiera XML:en
Högra panelen fylls med indragen, välformad XML som vilken standardenlig XML-parser som helst accepterar. Kopiera rakt in i din SOAP-begäran, dokumentation, fixture eller XSD-exempel.
När det faktiskt räddar dagen
XML-baserad dokumentation för ett GraphQL-API
Intern dokumentation eller partnerdokumentation som lever i XML (DITA, DocBook, XSD-uppbackade referenser). Klistra in schemat och få exempel-XML-payloads som matchar de riktiga typerna — ingen handöversättning.
Generera XML-fixtures från ett schema
Kontrakts- och snapshot-tester eller en mock-server som talar XML. Ge den schemat du redan har och få konsekventa fixture-XML:er med varje lista, nullable och nästlad typ på rätt plats.
Brygga till äldre SOAP-klienter
Ett partnerssystem tar bara XML-payloads men din backend talar GraphQL. Klistra in frågan och svarstypen och få ett startande XML-body att stoppa in i SOAP-begäran.
Schemamigrering & analys
Flytta från GraphQL till ett XML-baserat API (eller bara jämföra de två formerna). Visa en XML-version sida vid sida av varje typ så att granskare som inte läser SDL hänger med.
Vanliga frågor
Hur hanteras type, input, enum, interface och union?
type och input blir container-element med ett barn per fält. enum-värden kommer igenom som vanlig strängtext (enum-namnet, versaler, precis som deklarerat i SDL:en). interface löses upp mot sina fält plus fälten för implementerande typ när vi känner till den konkreta typen. union löses upp mot den matchande medlemmens form. Se referensen för GraphQL type language för de fullständiga reglerna.
Vilka standardvärden används för String, Int, Float, Boolean och ID?
String och ID blir textinnehåll. Int är ett vanligt heltal. Float är ett decimaltal utan inledande nollor. Boolean är texten med små bokstäver true eller false. Det stämmer med skalärdefinitionerna i GraphQL-specifikationen, så utdatan går rent genom en XML-parser.
Hur behandlas non-null (!)- och list ([T])-markörer?
Non-null (String!) behandlas som ett fält som måste dyka upp — nullable-fält utan värde kommer igenom som tomma element så att dokumentformen förblir förutsägbar. Listor ([OrderItem!]!) blir ett container-element med ett barn per objekt, namngivet efter elementtypen — t.ex. items: [OrderItem!]! blir <items><OrderItem/><OrderItem/></items>. Nästlade listor ([[Int]]) nästas på samma sätt.
Löses fragment upp?
Ja. Namngivna fragment (...OrderFields) och inline-fragment (... on Order { ... }) bakas in på plats så att XML:en blir platt och självförsörjande. Du behöver inte klistra in fragment-definitionerna separat — ligger de i samma block kopplar verktyget ihop dem. Det matchar den vanliga körningsmodellen för frågor, där fragment sprids ut i selection set:et innan svaret byggs.
Vad gäller egna skalärer som DateTime?
Välkända egna skalärer (DateTime, Date, Time, UUID, JSON) skrivs ut som ISO-8601-text eller strängifierade värden enligt konvention — i linje med vad de flesta skalärbibliotek gör. Okända egna skalärer faller tillbaka på strängtext så inget tappas i tysthet. Behöver du ett specifikt format, efterbearbeta XML:en eller döp om skaläret.
Kan jag klistra in en fråga med argument, inte bara ett schema?
Ja. Klistra in en query med variabler och argument — t.ex. query GetOrder($orderId: ID!) { order(id: $orderId) { ... } } — så kommer argumenten igenom som attribut på rotelementet. De valda fälten bestämmer vilka delar av svarsformen som serialiseras, så XML:en matchar det frågan faktiskt skulle returnera, inte hela typen.
Andra verktyg du kan behöva
GraphQL till XML är bara en pusselbit. De här verktygen funkar bra ihop med det: