Command Palette

Search for a command to run...

JSON para TypeScript: Gere interfaces precisas a partir de dados reais da API

JSON para TypeScript: Gere interfaces precisas a partir de dados reais da API

T
Toolz Team
|Jul 21, 2026|24 min ler

Parte da coleção Ferramentas de dados

json para digitar

Gere interfaces de TypeScript de qualquer amostra JSON. Inferir tipos aninhados, mescla matrizes de objetos em uma única interface, marca chaves anuláveis e ausentes opcionais e emite código exportável limpo. 100% do lado do cliente.

Usar json para digitar

O bug que finalmente me fez parar de escrever à mão tipos de API foi embaraçosamente pequeno Um endpoint de pagamentos retornado discount: null para clientes sem um, e EU tinha digitado discount: number porque a única resposta que EU olhei enquanto escrevia a interface aconteceu de ser um cliente com um desconto TypeScript foi perfeitamente feliz O compilador não tinha como saber I & #39; d mentiu para ele Três semanas depois a .toFixed(2) nesse campo, foi lançado a produção exatamente para o subconjunto de usuários que menos importavam para meus testes e mais para a fatura.

Esse é o problema de digitar uma API manualmente: você digita o que você acreditar o endpoint retorna, e o compilador obedientemente impõe sua crença em vez da realidade Toda garantia que o TypeScript lhe dá downstream é tão boa quanto aquela primeira interface escrita à mão, e não há nada na cadeia de ferramentas que a verifique em relação a uma resposta real Você obtém toda a cerimônia de digitação estática sem nenhuma segurança, o que é indiscutivelmente pior do que nenhum tipo - pelo menos o código não digitado o deixa desconfiado.

Gerar tipos de uma carga real inverte a direção Em vez de descrever o que você acha que é a forma, você pega uma resposta que o servidor realmente enviou e deriva a forma dela A saída é mecânica: sem otimismo, sem campos que você esqueceu que existiam, não number onde os dados dizem number | null. Eu construo [Toolz.dev](/e coloco um navegador baseado Conversor JSON para TypeScript lá isso faz isso, mas este guia é sobre as próprias regras de inferência - o que um gerador pode descobrir, o que ele só pode adivinhar e onde você ainda precisa pensar.

tl;dr: Para converter JSON para TypeScript, infira cada chave' s digite a partir de seu valor (string, number, boolean, null), extrair objetos aninhados em suas próprias interfaces nomeadas, e mesclar matrizes de objetos em uma única interface de elemento onde qualquer chave faltando em alguns membros torna-se opcional Decida deliberadamente se null meios key?: T ou key: T | null- essa escolha depende se sua API omite campos ausentes ou os envia como nulos A inferência reflete apenas a amostra que você fornece, portanto, use uma carga representativa com vários registros e trate a saída como um primeiro rascunho revisado em vez de um contrato concluído.

Por que gerar tipos TypeScript a partir de JSON em vez de escrevê-los?

A resposta honesta é que os tipos escritos à mão derivam e os tipos gerados don' t. Quando o backend adiciona um campo, sua interface escrita à mão silenciosamente permanece errada; nada de erros, porque propriedades extras em uma resposta são invisíveis para um tipo que não & #39; t mencioná-los Quando o backend muda id de um número para uma string, sua interface continua insistindo nele e no 39; é um número e o TypeScript continua concordando, até que algo concatene em vez de adicionar.

There' s também o argumento tédio simples Uma resposta REST típica tem trinta teclas em quatro níveis de aninhamento Transcrever que à mão leva dez minutos de trabalho mecânico puro, e trabalho mecânico realizado por seres humanos tem uma taxa de defeito Você vai digitar um nome de chave Você vai perder o único campo que & #39; s uma matriz de objetos em vez de uma matriz de strings O gerador não vai.

Mas a razão mais forte é que a geração dá forma visível. Cole uma resposta em um conversor e você verá imediatamente as coisas que você e #39; ter encoberto a leitura bruta de JSON: isso metadata na verdade, é um objeto profundamente aninhado, isso tags às vezes está vazio, que metade das chaves em sua lista paginada estão faltando em alguns registros A interface gerada é um resumo da estrutura real do data' s, e lê-lo é muitas vezes a maneira mais rápida de entender um endpoint que você fez' t write. I' usei-o como uma etapa de documentação mais de uma vez em APIs cujos documentos eram mentira.

Onde isso se encaixa ao lado de suas outras ferramentas de dados: se você & #39; estiver inspecionando a carga em vez de digitá-la, o formatador json é a primeira parada melhor e se você & #39; estamos comparando duas respostas para ver o que mudou entre as versões, o json diff responde isso diretamente.

Como a inferência de tipo do JSON realmente funciona?

JSON tem seis tipos de valor, por RFC 8259: objeto, matriz, string, número, true/false, e null. TypeScript' s tipos primitivos mapear em quatro desses quase diretamente O trabalho interessante é inteiramente nos outros dois.

Primitivos são triviais. Um valor de string implica string. Um número implica number- observe que JSON tem um tipo numérico, então não há informações nos dados informando se 1 é um número inteiro ou flutuante, e TypeScript não & #39; t distinguir de qualquer maneira. true ou false implica boolean. Esta parte não tem ambiguidade.

Objetos se tornam interfaces. Cada valor de objeto torna-se uma interface nomeada, e a chave em que apareceu fornece o nome, convertido para PascalCase Uma chave owner produz interface Owner. Nidificação é recorrente: um objeto dentro de um objeto produz uma segunda interface referenciada a partir da primeira Isso importa mais do que parece A alternativa - inlining cada forma anonimamente aninhada - produz uma única declaração ilegível e não lhe dá nada de importável:

// Inlined: technically correct, practically useless
interface Project {
  owner: { id: number; email: string; twoFactor: boolean }
}

// Extracted: you can import and reference Owner on its own
interface Project {
  owner: Owner
}

interface Owner {
  id: number
  email: string
  twoFactor: boolean
}

Uma vez Owner existe como um nome, uma função que leva apenas o proprietário pode ser digitada (owner: Owner) => void. Com a versão inlined você' estaria escrevendo Project['owner'] em todos os lugares, o que funciona, mas lê mal.

Matrizes são onde vivem as decisões reais. Um tipo array' s é a união de seus tipos de elementos, então [1, 2, 3]number[] e [1, "a"](number | string)[]. Observe os parênteses naquele segundo - sem eles, number | string[] significa algo totalmente diferente (um número ou uma matriz de strings) e geradores que esquecem esse código de emissão que compila, mas descreve a coisa errada.

Matrizes vazias são um beco sem saída honesto. "tags": [] diz-lhe uma chave existe e detém uma matriz; ele não lhe diz nada sobre o que vai nele A saída correta é unknown[], e você deve ler isso como o gerador se recusando a adivinhar, em vez de como uma resposta acabada Preencha-o em si mesmo a partir da documentação, ou encontre uma amostra onde a matriz é & #39; t vazio.

Por que matrizes de objetos são mescladas em vez de sindicalizadas?

Esta é a única decisão que separa um gerador você' d usar de um você'd abandonar após cinco minutos.

Considere uma resposta paginada onde os registros são 't perfeitamente uniforme - ou seja, toda resposta paginada real:

{
  "rows": [
    { "id": 1, "name": "Ada", "nickname": "The Countess" },
    { "id": 2, "name": "Grace" }
  ]
}

Trate cada elemento de forma independente e você obterá uma união de duas interfaces: rows: (Row1 | Row2)[]. Isto é tecnicamente a leitura mais precisa da amostra, e é inútil Todo acesso a row.nickname agora requer estreitamento, porque TypeScript can' t saber qual membro da união você tem Estenda isso para uma resposta de cinquenta registros com vários campos opcionais e você obterá uma união de dezenas de interfaces quase idênticas Ninguém quer isso.

A leitura útil é que esses dois objetos são duas instâncias de uma entidade, e nickname é um campo que Grace faz e#39;tem:

interface Row {
  id: number
  name: string
  nickname?: string
}

interface T {
  rows: Row[]
}

Isso' é uma mesclagem: colete todas as teclas vistas em todos os elementos e marque uma tecla opcional se ela' estiver ausente em qualquer um deles. Ele corresponde à forma como os dados são realmente produzidos - uma tabela de banco de dados, um serializador, algumas colunas anuláveis - e produz tipos que você pode usar sem cerimônia. O nome do elemento da matriz também é singularizado, portanto releases rendimentos Release em vez de Releases, porque releases: Releases[] parece um bug mesmo quando está 't.

A compensação é real e vale a pena afirmar claramente: a fusão assume que a matriz é homogênea Se você tiver uma matriz genuinamente heterogênea - uma alimentação de eventos com formas diferentes, discriminados por a type campo - mesclar achata variantes distintas em uma interface onde quase tudo é opcional Isso' s o modelo errado, e it' s um caso onde você deve tomar a saída gerada como um ponto de partida e mão-escrever uma união discriminada adequada Os geradores don' t saber o seu domínio Este mescla objetos e uniões todo o resto, que é certo na maioria das vezes e errado de uma forma que você pode detectar imediatamente.

Null deve se tornar uma chave opcional ou um membro do sindicato?

Ambas as convenções são defensáveis e a diferença é digna de nota, então decida de propósito em vez de aceitar o que sua ferramenta padrão.

Dado { "retiredAt": null }, há duas leituras:

interface A { retiredAt?: string }      // the field may be absent
interface B { retiredAt: string | null } // the field is present and may be null

Não são intercambiáveis. Em A, retiredAt é string | undefined e a chave pode não existir no objeto. Em B, a chave sempre existe e seu valor pode ser null. Sob strictNullChecks- qual o Manual TypeScript recomenda e sobre o qual você deve se envolver - ambos forçam você a lidar com o caso ausente, mas forçam verificações diferentes e serializam de maneira diferente. JSON.stringify omite undefined propriedades inteiramente e emite null para nulos, a escolha se propaga até o fio.

A resposta certa depende do comportamento real da API e do #39;, que nenhum gerador pode ver em uma amostra:

Seu comportamento API&#39 Modelo correto por que
Omitir a chave quando houver ' não tem valor key?: T A chave genuinamente é & #39; t lá; opcional é preciso
Sempre envia a chave, null quando vazio key: T | null A chave está sempre presente; ? permitiria erroneamente a ausência
Inconsistente - às vezes omitido, às vezes nulo key?: T | null Ambos os casos são reais; modele ambos
Envia null apenas nas respostas de erro Nenhum dos dois - modele o erro separadamente Um campo anulável está escondendo uma união de formas de resposta

Essa última linha é aquela em que vale a pena pausar Um campo que vai nulo apenas em casos de falha é um sinal de que o ponto final retorna duas coisas diferentes usando uma forma, e a correção é uma união discriminada em um campo de status, não uma propriedade anulável A geração de tipos surge nesse padrão; ele não resolve & #39; t resolvê-lo.

O padrão do conversor é key?: T porque omitido-quando-ausente é a convenção mais comum nas APIs JSON I & #39; tem trabalhado com, e porque compõe melhor com a fusão de array descrita acima (uma chave faltando em alguns registros e uma chave que & #39; nulo em alguns registros são modelados da mesma maneira).Desligue a opção e null permanece na união em vez disso. Nenhum dos dois é um truque; escolha aquele que sua API realmente faz.

E quanto às chaves que são & #39; t identificadores TypeScript válidos?

As chaves de objeto JSON são strings arbitrárias. Nomes de propriedades TypeScript em um bare key: T posição não são - eles têm que ser identificadores válidos Então "content-type", "2fa", "user.name", e "" são todas chaves JSON legais que não podem ser escritas sem aspas em uma interface.

A correção é citar, e it' não é uma solução alternativa - os nomes das propriedades cotadas são TypeScript comuns:

interface Headers {
  "content-type": string
  "2fa": boolean
  class: string
}

Essas propriedades são acessadas com notação de colchetes (headers["content-type"]), que é um pouco mais prolixo, mas totalmente seguro para o tipo. Observe isso class does't precisa citar: palavras reservadas são perfeitamente legais como nomes propriedade& #39; são ilegais como identificadores A restrição só se aplica onde TypeScript espera um identificador - e é por isso que a mesma palavra precisa de manipulação quando se torna uma interface nome.

Os nomes de interface derivados de tais chaves precisam de mais trabalho do que citar. 2fa PascalCases para 2fa, que pode & #39; t iniciar um identificador, então ele obtém um prefixo. Dois objetos aninhados diferentes, ambos sob chaves nomeadas owner ambos gostariam de ser Owner, então o segundo se torna Owner2. Estes são detalhes sem glamour, e eles & #39; são exatamente os detalhes que decidem se a saída gerada compila ou precisa de quinze minutos de reparo manual antes que isso aconteça. O teste em que seguro o conversor é simples: cole qualquer coisa válida e a saída deve ser compilada strict sem edições.

Interfaces ou aliases de tipo?

O gerador emite qualquer um das duas As diferenças práticas são estreitas, mas reais, e sua base de código provavelmente já tem uma opinião codificada em sua configuração de fiapos.

interface User {} suporta a fusão de declarações - declare o mesmo nome de interface duas vezes e TypeScript combina-os That' s essencial para aumentar os tipos de bibliotecas que você não & #39; t control, e uma footgun em qualquer outro lugar, uma vez que duas declarações não relacionadas com o mesmo nome silenciosamente mesclar em vez de erro Interfaces também suportam extends, que produz mensagens de erro ligeiramente melhores do que os tipos de interseção quando uma restrição falha.

type User = {} can't mesclar, que geralmente é um recurso, e it's requerido para qualquer coisa que seja & #39; t uma forma de objeto: uniões, tuplas, tipos mapeados, tipos condicionais Uma raiz que é & #39; t um objeto JSON - uma matriz de números, uma string nua - só pode ser expressa como um alias, então type Nums = number[] é o que você obtém independentemente da configuração.

Para tipos de API gerados, inclino-me para interface(em inglês), principalmente porque as mensagens de erro são marginalmente melhores e porque o risco de fusão é teórico quando cada nome vive em um arquivo gerado Mas isso está próximo de um lançamento de moeda, e a consistência com o código circundante importa mais do que os méritos Se sua configuração ESLint tiver @typescript-eslint/consistent-type-definitions defina de qualquer maneira, combine e pare de pensar nisso.

Como isso é diferente de JSON Schema para TypeScript?

Estes resolvem problemas genuinamente diferentes e vale a pena ser preciso, porque & quot; JSON para TypeScript" e " Esquema JSON para TypeScript" estão separados por uma palavra e frequentemente confundidos.

JSON para TypeScript é uma inferência de um exemplo. Entrada: um valor. O gerador observa o que' s lá e generaliza Ele não pode saber se um campo é necessário, se uma string é restrita a um enum, se um número tem um mínimo, ou se a única amostra que você colou é representativa It' s indução a partir de uma única observação, com tudo o que implica.

JSON Schema to TypeScript é a tradução de uma declaração. Entrada: a Esquema JSON documento, que já indica tipos, required arrays, enums, formatos e restrições O gerador é & #39; t adivinhando - it & #39; s transliterando um contrato existente em sintaxe TypeScript. required mapas para propriedades não opcionais; um enum mapeia para uma união literal de strings; oneOf mapeia para um tipo de união.

A regra segue diretamente: se existir um esquema, use-o. Um esquema JSON, uma especificação OpenAPI, a .proto arquivo ou um esquema GraphQL é confiável de uma forma que uma resposta amostrada nunca existe. A inferência é o que você busca quando não existe esquema - um endpoint interno não documentado, uma API de terceiros cujos documentos são obsoletos, um formato de arquivo de configuração que cresceu organicamente, um dispositivo elétrico contra você e #39; estão escrevendo testes contra. Que, para ser justo, descreve uma grande fração do JSON com o qual qualquer um de nós realmente lida.

There's um caminho intermediário que vale a pena mencionar: use inferência para bootstrap, então mantenha à mão Gere a interface a partir de uma resposta real para obter a forma e os nomes dos campos certos, depois edite - aperte a string para uma união literal onde você conhece os valores permitidos, corrija um unknown[] a amostra deixada vazia, divida uma interface mesclada em uma união discriminada adequada O gerador faz os 90% mecânicos e você aplica o conhecimento de domínio que estruturalmente não pode ter.

Onde a inferência erra?

Uma lista curta e honesta Cada um deles é uma limitação da abordagem, não um bug em uma ferramenta específica, e conhecê-los é a diferença entre usar bem os tipos gerados e ser queimado por eles.

Amostras únicas subdeterminam o tipo. Um campo que's number em sua amostra pode estar null em 5% dos registos Um campo que o & #39; s presente nos três registos que colou poderá ser opcional em todo o conjunto de dados completo A inferência reporta o que viu Colar mais registos - idealmente uma página real de resultados em vez de um objecto escolhido a dedo - e os opcionais ficam significativamente mais precisos.

Cordas escondem seus tipos reais. carimbos de data/hora ISO, UUIDs, URLs e endereços de e-mail são apenas string para um analisador JSON. "2026-07-16T09:00:00Z" é semanticamente uma data; nada nos dados diz isso Se sua base de código tiver uma marca ISODateString digite, você e #39; estamos substituindo-o manualmente.

Os números perdem distinções de precisão. JSON's tipo de número único significa um ID que's um número inteiro de 64 bits no servidor chega como um número JavaScript e pode já ter perdido precisão antes que seu gerador o veja - Number.MAX_SAFE_INTEGER é sobre 9×10¹5, e Twitter famosamente aprendeu isso da maneira mais difícil Se sua API envia inteiros grandes como strings, que & #39; s porquê, e o gerado string está correto.

Os valores literais se parecem com seus tipos gerais. "status": "active" infere string, não "active" | "archived" | "pending". O tipo mais estreito é mais útil e nenhuma amostra pode provar isso Esta é a edição manual mais comum que faço para a saída gerada.

Contentores vazios não dizem nada. []unknown[] e {} dá uma interface vazia Ambos são o gerador sendo honesto.

Nada disso torna a inferência insegura - torna-a uma rascunho. O fluxo de trabalho que funciona é: gerar, ler a saída com cuidado, corrigir as quatro ou cinco coisas que você sabe que a amostra poderia & #39; t dizer, commit. Isso & #39; ainda é uma ordem de magnitude mais rápida e precisa do que transcrever trinta chaves à mão, que é a alternativa real.

Meu JSON é carregado em algum lugar?

Não, e esta é uma categoria de ferramenta onde a pergunta merece uma resposta real em vez de um distintivo.

Pense no que & #39; s no JSON you' d colar em um gerador de tipos It' s uma resposta API, o que significa que ele plausivelmente contém um token de portador, um identificador de sessão, um e-mail do cliente, um ID de usuário interno, um nível de preços, um segredo webhook That' s não hipotético - it' s o caso modal, porque o ponto principal é que você pegou um verdadeiro resposta para digitar contra.

Qualquer conversor do lado do servidor recebe necessariamente essa carga útil. Pode não registrá-lo e provavelmente não, & #39; t, mas você & #39; está ampliando a confiança que você não tem & #39; tem que estender e, dependendo dos dados, você pode estar criando um problema de conformidade para uma tarefa que não tem nada a ver com tocar uma rede.

Inferência de tipo é computação pura sobre um valor analisado Não precisa de rede, nenhuma conta, nenhum armazenamento O conversor em Toolz.dev é algumas centenas de linhas de TypeScript livre de dependência em execução na sua guia; a carga útil é uma cadeia JavaScript no seu navegador' s memória e ele permanece lá Você pode verificar isso da maneira que você' d verificar qualquer tal afirmação - abrir a guia de rede e clicar em Gerar, ou desligar o seu wifi e vê-lo continuar funcionando Este é o mesmo princípio por trás de cada ferramenta no site, e I & #39; escreveu sobre por que isso importa mais amplamente em por que as ferramentas baseadas em navegador superam as do lado do servidor em busca de dados confidenciais.

Um exemplo trabalhado

Aqui e #39; s a amostra com a qual a ferramenta é fornecida, que é deliberadamente construída para exercer todas as regras acima:

{
  "id": 4821,
  "name": "Toolz",
  "isPublic": true,
  "retiredAt": null,
  "owner": {
    "id": 12,
    "email": "[email protected]",
    "twoFactor": false
  },
  "tags": ["developer", "privacy", "browser"],
  "releases": [
    { "version": "1.0.0", "downloads": 1420, "notes": "First cut" },
    { "version": "1.1.0", "downloads": 3310 }
  ]
}

Com a raiz nomeada Project, isso gera:

export interface Project {
  id: number
  name: string
  isPublic: boolean
  retiredAt?: null
  owner: Owner
  tags: string[]
  releases: Release[]
}

export interface Owner {
  id: number
  email: string
  twoFactor: boolean
}

export interface Release {
  version: string
  downloads: number
  notes?: string
}

Leia o que aconteceu. owner foi extraído em sua própria interface e referenciado pelo nome. tags desabou para string[] porque cada elemento era uma string. releases fundiu seus dois membros em um Release- singularizado - e notes tornou-se opcional porque o segundo lançamento não tinha & #39; t tem um. retiredAt tornou-se opcional porque seu único valor observado era nulo.

E agora leia o que você'd corrigir. retiredAt?: null é o gerador & #39; s relatório honesto que ele nunca viu um valor não nulo, e it& #39; s inútil como um tipo - you& #39; d mudá-lo para retiredAt?: string porque você sabe que & #39; é um carimbo de data/hora quando presente. Essa edição única é toda a lição: o gerador obteve a estrutura de sete teclas, o aninhamento, a mesclagem do array e a opcionalidade em uma pasta, e deixou você com a única decisão que exigia saber o que o campo significa.

FAQ

Como faço para converter JSON em uma interface TypeScript?

Cole seu JSON no conversor, defina o nome do tipo raiz como o recurso é chamado e pressione Gerar. Ele infere o tipo de cada tecla, puxa objetos aninhados para fora em suas próprias interfaces nomeadas, mescla matrizes de objetos em um único tipo de elemento e gera código que você pode copiar diretamente em um .ts arquivo. Lá e #39; não há inscrição nem upload - a inferência é executada em seu navegador.

O que acontece com matrizes de objetos?

Eles' são mesclados em uma interface descrevendo um único elemento, e a propriedade é digitada como uma matriz dela Qualquer chave que aparece em alguns membros da matriz, mas não em outros, torna-se opcional Isso corresponde a como os dados paginados reais se comportam, onde os registros vêm de uma tabela e algumas colunas são anuláveis O único caso que ele lida mal é uma matriz genuinamente heterogênea de diferentes tipos de eventos, que você deve converter manualmente em uma união discriminada.

Null deve se tornar uma chave opcional ou uma união com null?

Depende se sua API omite campos ausentes ou os envia como nulos. Se os omite, key?: T é preciso Se a chave está sempre presente e às vezes nula, key: T | null é preciso e usado ? permitiria erroneamente que a chave faltasse. O padrão do conversor é opcional e permite alternar, porque os dois serializam de forma diferente - JSON.stringify elimina propriedades indefinidas, mas emite propriedades nulas.

Pode inferir tipos exatos de uma única amostra JSON?

Ele infere tipos precisos para aquela amostra, que é o & #39; t a mesma coisa Um campo que & #39; s um número no seu registo pode ser nulo noutros; um campo presente em todos os três registos que colou pode ser opcional em todo o conjunto de dados completo Utilize uma carga representativa com vários registos em vez de um objecto escolhido a dedo, e trate a saída como um rascunho revisto em vez de um contrato terminado.

Qual é a diferença entre JSON para TypeScript e JSON Schema para TypeScript?

Esta ferramenta infere tipos de um valor de exemplo; esquema JSON para TypeScript traduz um esquema formal que já declara tipos, campos obrigatórios e enums O esquema é autoritário e a inferência é um palpite, então se você tiver um esquema JSON, uma especificação OpenAPI ou um esquema GraphQL, use-o A inferência é para o caso muito comum em que nenhum esquema existe e tudo o que você tem é um corpo de resposta.

Como ele lida com chaves que são identificadores válidos do & #39; t?

Chaves com traços, pontos, espaços ou dígitos iniciais são citadas na saída, portanto "content-type" torna-se "content-type": string. That' s valid TypeScript, acessado com notação de colchetes Reservou palavras como class don't precisa citar como nomes de propriedade Os nomes de interface derivados de tais chaves são PascalCased e prefixados se eles' d começar com um dígito, e nomes em colisão obter um sufixo numérico para que a saída sempre compila.

Devo gerar interfaces ou aliases de tipo?

Combine o que sua base de código já faz - esta é principalmente uma questão de consistência Interfaces suportam a fusão de declarações e extends& t dar mensagens de erro marginalmente mais claras - Os aliases de tipo podem & #39; t fundir, o que é normalmente desejável, e são necessários para qualquer coisa que seja & #39; t uma forma de objecto Uma raiz que & #39; s uma matriz ou uma primitiva é emitida como um alias de qualquer maneira, uma vez que não há & #39; s nenhum objecto para declarar uma interface para.

Meu JSON foi carregado em um servidor?

Não. Todo o mecanismo de inferência é executado como JavaScript no seu navegador, sem chamadas de rede, sem registro e sem armazenamento Isso importa aqui mais do que para a maioria das ferramentas, porque o JSON você e #39; d colar em um gerador de tipos geralmente é uma resposta API real contendo tokens, registros de clientes ou IDs internos Abra sua guia de rede enquanto gera ou desconecte-se da Internet - ela continua funcionando.


Ferramentas relacionadas: formatador json Para inspecionar primeiro a carga útil, json para yaml e json para xml Para conversão de formatos e json diff Para detectar o que mudou entre duas respostas. Leitura adicional: O guia definitivo para ferramentas JSON e Guia de ferramentas de codificação do desenvolvedor.

Comments

0 comments

0/2000 characters

No comments yet. Be the first to share your thoughts!