Avaliador de JSON Patch (RFC 6902)｜Aplique as 6 operações e veja o resultado

Execute um JSON Patch sobre um documento direto no navegador, sem servidor. As seis operações padrão — add, remove, replace, move, copy e test — são aplicadas em ordem, e você recebe o JSON modificado junto com um rastreio legível do que cada operação fez. Se uma única operação falhar, todo o patch falha e o documento original é devolvido, exatamente como o RFC 6902 exige.

💡 Sobre esta ferramenta

Ao projetar ou revisar um endpoint PATCH, uma pergunta volta sempre: "se eu enviar este vetor de operações, como fica o documento depois?". Subir a API real, montar a requisição e ler a resposta é um ciclo lento, sobretudo quando a diferença entre move e copy, o resultado de um test ou o comportamento do token de acréscimo - ainda não estão claros.

Esta ferramenta reduz esse ciclo a duas caixas de texto. Cole um documento alvo e um vetor de operações: cada caminho é resolvido com a sintaxe JSON Pointer (RFC 6901) e as operações são aplicadas conforme a especificação. Quando algo falha, ela informa qual operação falhou (por exemplo op[2]) e por quê: caminho inexistente, índice do vetor fora do intervalo, valor de test que não coincide ou operação desconhecida. É voltada a desenvolvedores back-end, revisores de OpenAPI e quem usa kubectl patch --type=json e quer reproduzir o comportamento da especificação sem acionar um servidor real.

🧐 Perguntas frequentes

Q. Qual a diferença entre JSON Patch (RFC 6902) e JSON Merge Patch (RFC 7396)? R. JSON Patch é um vetor de operações explícitas (add, remove, replace, move, copy, test) aplicadas em ordem. O Merge Patch envia um documento parcial com o estado final desejado e usa null para apagar chaves; não tem move, copy nem test. Use JSON Patch quando precisar manipular vetores com precisão ou verificar uma pré-condição.

Q. Para que serve a operação test? R. É uma guarda que confirma se o valor em um caminho é o esperado antes de qualquer mutação. Colocar test /version == 15 no início faz o restante do patch ser aplicado só se o documento ainda estiver no estado que você supôs: uma forma de concorrência otimista para não sobrescrever a alteração de outra pessoa.

Q. O que acontece se uma operação falhar? R. O RFC 6902 trata o patch de forma atômica. Assim que uma operação falha, o patch inteiro é considerado falho e a ferramenta devolve o documento alvo original intacto. Não há aplicação parcial.

Q. O que significa o - em /user/tags/-? R. É o token especial de JSON Pointer que indica "o fim do vetor". Com add, o - acrescenta ao final; um índice numérico insere naquela posição.

Q. Como referencio uma chave que contém uma barra ou um til? R. Use o escape do RFC 6901: dentro de uma chave, escreva / como ~1 e ~ como ~0. Assim, uma chave chamada literalmente a/b é endereçada como /a~1b.

📚 Por que o JSON Patch combina tão bem com o PATCH do REST

O verbo PATCH do REST significa "atualização parcial", mas o próprio HTTP não define o formato do corpo. Carregar um JSON Patch nesse corpo permite descrever a mudança como uma sequência de operações em vez de reenviar o documento inteiro. Comparado ao PUT, a carga é pequena, e combinar as mutações com uma operação test evita sobrescrever em silêncio um campo que alguém alterou depois da sua leitura. O vetor de operações também serve como registro de auditoria legível: fica claro quem mudou qual caminho e como. Ferramentas como kubectl patch --type=json aceitam esse mesmo formato RFC 6902. Na prática, o caminho mais rápido para assimilar a diferença entre move e copy, ou para sentir como o test interrompe um patch, é alinhar algumas operações e observar o resultado em vez de reler a especificação.