Um olhar profundo sobre JSON vs. XML, Parte 3: XML e o futuro do JSON

Publicados: 2022-03-11
Relacionado: Um olhar profundo sobre JSON vs. XML, Parte 2: Os pontos fortes e fracos de ambos

Na Parte 2 deste artigo, examinamos mais de perto o JSON como intercâmbio de dados e avaliamos seus pontos fortes e fracos para aplicativos simples versus os complexos. O JSON se destaca como o formato legível por humanos mais conciso e compacto, mas sua simplicidade básica pode levar a implicações não intencionais quando usado para casos de uso complexos. Com o JSON como intercâmbio de dados, os desenvolvedores ficam por conta própria para implementar as funcionalidades que faltam no próprio JSON, resultando em soluções acopladas e fora do padrão que tentam suprir a lacuna. Para soluções corporativas inflexíveis em garantir uma operação livre de erros, o uso de JSON pode resultar em padrões indesejados que podem prejudicar a qualidade do código do sistema, a estabilidade e a resiliência a futuras incógnitas. O XML oferece recursos para ajudar os aplicativos a mitigar esse risco? As mesmas funcionalidades podem ser alcançadas com JSON? Uma análise mais detalhada do XML como intercâmbio de dados revelará seus pontos fortes na redução do risco de software e fornecerá aos desenvolvedores uma melhor compreensão dos padrões que podem ajudar a melhorar a qualidade de seus aplicativos.

Na Parte 3 deste artigo, iremos:

  1. Explore o XML como intercâmbio de dados e avalie seus pontos fortes no suporte a requisitos complexos.
  2. Discuta o futuro do JSON e explore soluções que trazem os pontos fortes do XML para o JSON para permitir que os desenvolvedores criem softwares mais estáveis ​​e mais resistentes a bugs e incógnitas futuras.
Relacionado: Uma análise profunda do JSON vs. XML, Parte 1: A história de cada padrão

XML é prontamente rotulado como a alternativa complexa e detalhada ao JSON. O site w3schools.com – uma referência popular para padrões da web – oferece apenas 58 palavras sobre o assunto “Por que JSON é melhor que XML” 1 . Uma avaliação tão simplista de JSON versus XML é enganosa, porque XML fornece muito mais do que apenas intercâmbio de dados. Na verdade, o XML não foi projetado apenas para troca de dados, mas sim como linguagem para especificar linguagens de marcação personalizadas para qualquer aplicativo. Com sua semântica estrita, o XML definiu um padrão para afirmar a integridade dos dados de documentos XML, de qualquer sublinguagem XML. Muitos desenvolvedores acreditam que “o XML falhou e foi substituído pelo JSON”, mas isso não poderia estar mais longe da verdade. Originalmente, o XML foi concebido para ser usado para todos os problemas de interoperabilidade de dados e até hoje permanece como “o formato mais usado no mundo para representar e trocar informações”. 2

JSON é simples e XML é poderoso

Na Parte 2 deste artigo, exploramos o intercâmbio de dados envolvendo contratos orientados ao consumidor (CDCs), evolução de protocolo e validação de mensagens. Com o JSON como intercâmbio de dados, nosso exemplo—Banco Europeu—foi desafiado a fornecer uma solução de redução de risco para o intercâmbio de dados com varejistas. O banco desejava padrões de software que resultassem em baixo acoplamento, alto encapsulamento e alta resiliência a futuras incógnitas. Com o JSON como intercâmbio de dados, no entanto, o banco foi apresentado com padrões que resultaram no oposto: baixo encapsulamento, alto acoplamento e menor resiliência a futuras incógnitas.

Vamos revisitar o exemplo do Banco Europeu e substituir JSON como formato de intercâmbio de dados por XML. As seguintes mensagens XML são equivalentes à mensagem JSON para cada tipo de identificador de conta: SWIFT, IBAN e ACH.

 <message xsi:type="swift" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>CTBAAU2S</code> </message> <message xsi:type="iban" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>DE91 1000 0000 0123 4567 89</code> </message> <message xsi:type="ach" xmlns="urn:bank:message" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <code>379272957729384</code> <routing>021000021</routing> </message>

Apesar da perda imediata na eficiência da contagem de bytes brutos, o XML justifica sua verbosidade suportando um escopo mais amplo em torno do intercâmbio de dados. Ao codificar os dados com JSON, conseguimos resolver os requisitos imediatos do intercâmbio de dados, mas nada para dar suporte a várias variantes de mensagens ou sua validação. Para abordar o escopo em torno dos contratos orientados ao consumidor, os desenvolvedores precisariam implementar um código personalizado que resultaria em um acoplamento lógico entre o formato da mensagem, seu conteúdo e a implementação funcional para seu processamento. Alternativamente, o desenvolvedor pode optar por montar um quebra-cabeça de uma coleção de bibliotecas e estruturas para atender aos requisitos mais altos. Ambas as abordagens resultam em uma cebola de camadas sobre o intercâmbio de dados que são acoplados diretamente ao aplicativo. Codificando os dados com XML, no entanto, conseguimos resolver muitas movimentações dos requisitos sem o acoplamento.

Os equivalentes de mensagens XML utilizam dois recursos específicos do padrão XML: namespaces e tipos de instância. O atributo xmlns="urn:bank:message" especifica o namespace da mensagem e o atributo "xsi:type" especifica seu tipo de instância, como "swift" , "iban" ou "ach" . Esses dois atributos são padrões XML que permitem que um processador de mensagens identifique o tipo da mensagem, bem como desreferencie o esquema que define as regras de validação.

O esquema XML representa o principal diferenciador entre JSON e XML. Com um esquema, um desenvolvedor pode encapsular a definição normativa do formato da mensagem em um meio separado do aplicativo e definir restrições de valor fornecendo regras de validação impostas por processadores XML. Um esquema de exemplo para o Banco Europeu (com namespace: xmlns="urn:bank:message" ), completo com descritores de tipo e restrições de valor, é o seguinte documento de esquema XML (XSD):

 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="urn:bank:message" targetNamespace="urn:bank:message"> <xs:complexType name="format" abstract="true"/> <xs:complexType name="swift"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="iban"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="ach"> <xs:complexContent> <xs:extension base="format"> <xs:sequence> <xs:element name="code"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\w{1,17}"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="routing"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:pattern value="\d{9}"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="message" type="format"/> </xs:schema>

Esse esquema XML é logicamente equivalente à função isValid(message) da Parte 2. À primeira vista, esse esquema XML é consideravelmente mais detalhado do que isValid(message) . A diferença fundamental entre os dois, no entanto, é que isValid(message) é acoplado ao aplicativo, e o esquema XML não é. O esquema XML é uma linguagem para expressar restrições sobre documentos XML e existem várias linguagens de esquema diferentes em uso generalizado, sendo as principais: definições de tipo de documento (DTDs), Relax-NG, Schematron e definições de esquema XML W3C (XSD ). 3 Para o Banco Europeu, o esquema XML fornece uma solução de risco reduzido para requisitos de camada superior sem o acoplamento.

Um esquema XML resulta em menor risco de software. Com XML, as regras para validação de mensagens são expressas em uma linguagem de esquema que é desvinculada e, portanto, não acoplada ao aplicativo. Como o esquema XML é totalmente desvinculado do sistema, o significado lógico do formato da mensagem e a implementação funcional para seu processamento são desacoplados. O esquema XML fornece ao Banco Europeu uma camada encapsulada que é exclusivamente responsável pelo contexto de validação de mensagens, variabilidade, controle de versão e muito mais.

O esquema XML representa a definição normativa do contrato orientado ao consumidor. Para o Banco Europeu, isso fornece uma abordagem de redução de risco para reduzir $\xi_0$ mais próximo de 0. Como o esquema é desacoplado do banco e do varejista, ambas as partes podem usá-lo para validar e fazer cumprir o contrato.

texto alternativo
O contrato orientado ao consumidor é especificado em um esquema XML, fornecendo definição normativa de regras de execução que podem ser exercidas por cada parte. Como o XSD é desacoplado do aplicativo, ele pode ser compartilhado com cada participante do protocolo.

Por que o esquema XML é tão detalhado?

A especificação do esquema XML fornece uma linguagem para desenvolvedores implementarem padrões estruturais e lógicos usados ​​para definir e restringir todas as partes constituintes de qualquer documento XML. Com um esquema XML, os desenvolvedores podem incorporar significados mais profundos em cada parte estrutural e lógica de um documento XML. Por exemplo, o esquema XML permite:

  1. Definição de restrições de expressão regular para strings constituintes,
  2. Definição de intervalos e formatos para números constituintes,
  3. Definição de elementos e atributos constituintes obrigatórios e opcionais,
  4. Definição de requisitos chave e de referência em um documento e muito, muito mais.

Com um esquema XML, um sistema pode contar com validadores XML genéricos para afirmar a validade de cada mensagem de entrada, reduzindo intrinsecamente o “espaço de erro” $\xi_0$ mais próximo de 0 e isolando automaticamente a lógica de negócios de entradas errôneas.

O Risco do Desenvolvimento Futuro

Os sistemas podem utilizar recursos inerentes da especificação XML para reduzir o risco de desenvolvimento futuro do software. Ao concordar com um contrato normativo na forma de um esquema XML, os sistemas definem as regras e restrições para todos os objetos e propriedades (elementos e atributos, para XML) a serem trocados. Os sistemas podem, a partir de então, alavancar o escopo mais amplo da especificação do XML para tratar da variabilidade de mensagens, controle de versão de protocolo e validação de conteúdo. Por exemplo, namespaces XML fornecem mensagens XML com as informações necessárias para:

  1. Identifique a versão da mensagem.
  2. Desreferenciar o esquema normativo do contrato.
  3. Validar a exatidão de um documento.

Com a ampla variedade de recursos e capacidades oferecidos pelo esquema XML, a maioria dos requisitos complexos que envolvem o intercâmbio de dados podem ser resolvidos com o próprio XML. É a isso que o Dr. Charles Goldfarb estava se referindo quando disse “[XML é] o santo graal da computação”. 4

O esquema XML ajuda os aplicativos a serem resilientes a erros e maleáveis ​​a alterações futuras.

XML é uma especificação amplamente aceita e criteriosamente examinada com inúmeras bibliotecas disponíveis para todas as plataformas para auxiliar no processamento e validação de documentos XML. Com XML como formato de intercâmbio de dados, um desenvolvedor é capaz de resolver os requisitos imediatos, bem como aqueles relativos a contratos orientados ao consumidor, variabilidade de mensagens, versão de protocolo e validação de conteúdo. O XML permite que um desenvolvedor proteja o risco de requisitos complexos e, mais importante, de futuras incógnitas.

XML é muito mais do que intercâmbio de dados e pode ser usado para resolver problemas muito maiores do que com JSON. Quando visto dessa perspectiva, o escopo do XML cobre uma parte maior da cebola, por meio do qual várias das camadas da cebola estão contidas no escopo do próprio XML.

texto alternativo
uma. XML como intercâmbio de dados.
b. Validação de mensagem encapsulada com um esquema XML. Este código é desacoplado do aplicativo.
c. Validação de mensagem não encapsulada. Este código é misturado com as camadas de negócios.
d. A aplicação.

Ao escolher o melhor formato de intercâmbio de dados para um aplicativo, é apenas o centro da cebola que nos preocupa ou é a cebola inteira?

As diferenças fundamentais entre JSON e XML

XML oferece muito mais do que intercâmbio de dados e pode ser usado para resolver problemas muito maiores do que com JSON. O escopo de requisitos complexos em torno do intercâmbio de dados é acomodado pelo XML, permitindo que os sistemas utilizem bibliotecas e estruturas em conformidade com um padrão, desacoplado do aplicativo.

XML é uma especificação que aborda o escopo de requisitos complexos por design e é um padrão definido pelo W3C e suportado por todos os fornecedores de software e plataformas de linguagem relevantes. Ao usar XML como intercâmbio de dados, os aplicativos lucram automaticamente com uma redução sistemática do risco de software.

O futuro do JSON

O JSON está inegavelmente aqui para ficar. Com o JavaScript como a plataforma de desenvolvimento mais usada atualmente, o JSON se tornou o formato de intercâmbio de dados mais proeminente. Para pequenos projetos com baixa complexidade, o JSON é perfeito. Mas à medida que nos esforçamos para criar aplicativos maiores e melhores para o futuro, a complexidade geral do nosso software está destinada a aumentar. Com os poderosos recursos do XML como exemplo, vários grupos se esforçaram para inventar padrões semelhantes para JSON.

A deficiência fundamental do JSON é sua falta em fornecer um padrão geral para a descrição normativa dos constituintes lógicos de seus documentos.

Esquema JSON

Em 2009, um grupo iniciou o esquema JSON 5 , que é um vocabulário para anotar e validar documentos JSON. O esquema JSON usa a semântica JSON para definir um conjunto de regras e restrições para os constituintes de documentos JSON, e vários projetos em várias plataformas implementaram bibliotecas que suportam a especificação do esquema JSON. Embora ainda não seja um padrão oficial, o projeto de esquema JSON fornece uma solução para um escopo de requisitos semelhante à especificação do esquema XML. Com o vocabulário de esquema JSON, os desenvolvedores podem definir as regras e restrições lógicas e estruturais dos documentos JSON. O esquema pode então ser usado para auxiliar no processamento e validação de documentos JSON com bibliotecas desacopladas do aplicativo, reduzindo assim a necessidade de mistura de código não encapsulado no aplicativo. Com o esquema JSON, um desenvolvedor pode escolher JSON como o formato de seu intercâmbio de dados e endereçar, de forma mitigada pelo risco, os requisitos complexos não endereçados anteriormente apenas com JSON.

O projeto de esquema JSON é um esforço da comunidade e, após uma década de revisões, permanece como a especificação predominante para esquemas JSON. Embora ainda não seja um padrão, a popularidade do projeto de esquema JSON indica o nível de interesse para tal solução. Conceitualmente, a especificação do esquema JSON se assemelha ao esquema XML, mas uma comparação dos dois revela diferenças entre seus modelos, recursos e semântica. Por exemplo, embora a linguagem defina uma ampla variedade de propriedades para restringir os limites dos tipos de valor JSON, seus vários atributos permitem a expressão de definições de esquema autocontraditórias.

Por exemplo, o trecho a seguir define um tipo de "object" que contém três propriedades: "number" , "street_name" e "street_type" .

 { "type": "object", "properties": { "number": { "type": "number" }, "street_name": { "type": "string" }, "street_type": { "type": "string", "enum": ["Street", "Avenue", "Boulevard"] } } }

A definição de um tipo de "object" aceita restrições adicionais, uma das quais é "minProperties" . Ao modificar a definição de tipo "object" acima com um "minProperties": "4" , a definição se torna sem sentido, porque apenas três propriedades são definidas explicitamente para o objeto.

O esquema JSON tem um número consideravelmente grande e amplo de propriedades de restrição, muitas das quais são essenciais para confinar efetivamente documentos JSON e muitas das quais se sobrepõem umas às outras. Com propriedades de restrição que se sobrepõem em significado, o vocabulário do esquema JSON apresenta duas famílias de desafios:

  1. Requer uma curva de aprendizado maior dos desenvolvedores, devido ao amplo vocabulário e nuances inusitadas ou não convencionais em sua semântica.
  2. É mais difícil para as bibliotecas de validação implementarem, levando a soluções que implementam as áreas cinzentas de forma diferente, resultando em implementações inconsistentes.

A linguagem de esquema XML em si não está completamente livre de permitir a expressão de definições autocontraditórias, mas elas são muito menos e limitadas. Na verdade, a especificação do esquema XML foi desenvolvida com muita atenção tanto para a facilidade de uso para os desenvolvedores quanto para as bibliotecas que implementam a especificação. Além disso, o projeto de esquema JSON define apenas a especificação da linguagem de esquema, mas existem muitos projetos de comunidade que implementam essa especificação.

O validador de esquema JSON 6 é um projeto popular que implementa um validador de esquema JSON para a plataforma Java. Ao integrar esta biblioteca em um aplicativo Java, o aplicativo é capaz de afirmar a conformidade de todos os documentos JSON trocados. Outras implementações da especificação de esquema JSON estão disponíveis para várias plataformas.

Para o Banco Europeu, vamos usar o esquema JSON para implementar um esquema para mensagens JSON com identificadores de conta.

 { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "swift": { "type": "object", "properties": { "type": { "type": "string", "pattern": "swift" }, "code": { "type": "string", "pattern": "(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}" }, "required": ["type", "code"] } }, "iban": { "type": "object", "properties": { "type": { "type": "string", "pattern": "iban" }, "code": { "type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{0,2}" }, "required": ["type", "code"] } }, "ach": { "type": "object", "properties": { "type": { "type": "string", "pattern": "ach" }, "code": { "type": "string", "pattern": "\\w{1,17}" }, "routing": { "type": "string", "pattern": "\\d{9}" }, "required": ["type", "code", "routing"] } } } }

Esse esquema JSON define os 3 tipos de objeto: "swift" , "iban" e "ach" . Ele especifica padrões de expressão regular para afirmar que as informações da conta não são inválidas e declara "type" e "code" como propriedades obrigatórias para cada tipo, além de "routing" como uma propriedade obrigatória para o tipo "ach" . Com esse esquema JSON, o Banco Europeu pode validar sua entrada JSON para afirmar que o conteúdo da mensagem está correto para cada interação.

O esquema JSON traz muitos recursos de XML para JSON, mas ainda é um trabalho em andamento. Embora seja uma ótima solução que pode ser usada para proteger o risco de software, a especificação do esquema JSON não é perfeita. Devido à evolução informal de sua linguagem, a linguagem evoluiu em uma direção que omite características indiscutivelmente importantes e contém padrões de expressão estruturais e lógicos que são confusos e não convencionais. Por exemplo, a linguagem do esquema não tem a capacidade de definir tipos abstratos, o que pode levar os desenvolvedores a implementar soluções alternativas complicadas que resultam em um risco de software associado próprio. 7

O projeto de esquema JSON trouxe uma riqueza inestimável de contribuição para os conceitos por trás de uma linguagem de esquema para JSON. Apesar das deficiências na clareza de sua semântica, a linguagem de esquema JSON é uma solução versátil que traz muitos recursos de XML para JSON.

Para obter uma visão mais detalhada da especificação do esquema JSON, consulte Entendendo o esquema JSON.

JSONx

Em 2014, outro grupo iniciou o projeto JSONx, que aproveita diretamente o XML para fornecer uma solução igualmente poderosa para JSON. O projeto JSONx foi criado especificamente para a empresa e define a linguagem JSON schema definition (JSD), que é modelada de acordo com a especificação do esquema XML. Usando o esquema XML como seu modelo, o JSD define padrões estruturais e lógicos que têm uma grande semelhança com a linguagem de definição do esquema XML.

Para o exemplo do Banco Europeu, vamos usar a linguagem JSD para implementar um esquema para mensagens JSON com identificadores de conta.

 { "jx:ns": "http://www.jsonx.org/schema-0.3.jsd", "jx:schemaLocation": "http://www.jsonx.org/schema-0.3.jsd http://www.jsonx.org/schema-0.3.jsd", "message": { "jx:type": "object", "abstract": true }, "swift": { "jx:type": "object", "extends": "message", "properties": { "type": { "jx:type": "string", "pattern": "swift", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?", "nullable": false, "use": "required" } } }, "iban": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "iban", "nullable": false }, "code": { "jx:type": "string", "pattern": "[AZ]{2}\\d{2} ?\\d{4} ?\\d{4} ?\\d{4} ?\\d{4} ?[\\d]{0,2}", "nullable": false } } }, "ach": { "jx:type": "object", "properties": { "type": { "jx:type": "string", "pattern": "ach", "nullable": false }, "code": { "jx:type": "string", "pattern": "\\w{1,17}", "nullable": false }, "routing": { "jx:type": "string", "pattern": "\\d{9}", "nullable": false } } } }

À primeira vista, o esquema JSD é semelhante em expressão ao esquema JSON. Uma diferença, no entanto, é a semântica concisa do JSD em comparação com o esquema JSON. Específico para este exemplo, o JSD coloca a propriedade "use": "required" na definição que está sendo especificada, enquanto o esquema JSON associa essa propriedade ao objeto pai, exigindo que o nome dos valores corresponda ao nome da definição da propriedade. A restrição "use": "required" só é especificada na propriedade "code" do objeto "swift" e omitida das demais porque "use": "required" é o valor padrão. A linguagem JSD foi projetada levando em consideração todas essas nuances e oferece uma solução limpa e intuitiva para a expressão de esquemas JSON.

Desde o início, uma propriedade distintiva do projeto JSONx é sua principal intenção de fornecer clareza e utilidade aos desenvolvedores. Para conseguir isso, um recurso poderoso do JSD é sua conversibilidade para JSDx — a linguagem JSD pode ser expressa em arquivos JSON e também em arquivos XML. Ambos os formulários são traduzíveis individualmente e fornecem aos desenvolvedores a capacidade de usar ferramentas avançadas de edição de XML para auxiliar na criação de documentos JSD para serem validados ao vivo e livres de erros.

O esquema JSD acima pode ser expresso no seguinte formato JSDx:

 <schema xmlns="http://www.jsonx.org/schema-0.3.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.jsonx.org/schema-0.3.xsd http://www.jsonx.org/schema-0.3.xsd"> <object name="swift"> <property name="code" xsi:type="string" pattern="[AZ]{6}[A-Z0-9]{2}([A-Z0-9]{3})?" nullable="false" use="required"/> </object> <object name="iban"> <property name="code" xsi:type="string" pattern="[AZ]{2}\d{2} ?\d{4} ?\d{4} ?\d{4} ?\d{4} ?\d{0,2}" nullable="false"/> </object> <object name="ach"> <property name="code" xsi:type="string" pattern="\w{1,17}" nullable="false"/> <property name="routing" xsi:type="string" pattern="\d{9}" nullable="false"/> </object> </schema>

O formulário JSDx do JSD é poderoso porque fornece uma especificação clara, autovalidada e com risco reduzido para definir esquemas JSON.

A linguagem JSD é projetada para lidar com questões de definições autocontraditórias e conta com padrões padrão para a expressão de restrições. Projetadas em estreita semelhança com a linguagem de definição de esquema XML (XSD), as declarações de tipo JSD e as definições de restrições têm grande semelhança com estruturas equivalentes em XML. A especificação JSD(x) fornece uma solução completa para a definição de restrições estruturais e lógicas e é autodescritiva — fornecendo uma definição normativa da linguagem JSD(x) expressa na própria linguagem JSD(x). Para uma análise mais detalhada da especificação JSD(x), consulte JSON Schema Definition Language.

Além da linguagem JSD(x), o projeto JSONx fornece implementações de referência de processadores e validadores JSD(x), bem como uma API de associação de classe e gerador de código para a plataforma Java. Com a API de vinculação e o gerador, um desenvolvedor pode usar um esquema JSD(x) para gerar automaticamente classes para as definições de objeto no esquema desejado, que podem ser usadas para analisar e empacotar documentos JSON que estejam em conformidade com o esquema. As classes geradas fornecem uma ligação fortemente tipada entre o esquema e a plataforma Java, representando o uso, as restrições e os relacionamentos especificados no esquema. Com ligações fortemente tipadas ao esquema, o aplicativo reduz ainda mais o risco de software relacionado a modificações futuras que podem resultar em incompatibilidades.

Ao alavancar o compilador Java, as ligações fortemente tipadas identificam as incompatibilidades com erros de tempo de compilação, reduzindo efetivamente o risco de bugs relacionados ao processamento de mensagens próximo a zero. Esse padrão de engenharia permite que os desenvolvedores implementem alterações e resolvam incompatibilidades com rapidez e confiança, não precisando depender do tempo de execução para encontrar bugs ou casos de falha - e principalmente não depender dos usuários para tropeçar nos próprios bugs. A API de vinculação é implementada com anotações Java, o que permite que qualquer classe seja vinculada a um esquema JSD(x) com tipos fortes, mas de maneira leve. Os recursos de geração de código e vinculação fortemente tipados do JSONx suportam todo o escopo da especificação JSD(x), projetada especificamente para atender aos altos padrões de soluções corporativas.

A estrutura JSONx foi criada para soluções corporativas e oferece um alto padrão de qualidade e utilidade para sistemas complexos, bem como validação de erro de tempo de edição e facilidade de uso para desenvolvedores.

O mecanismo de vinculação JSD(x), processador e validador relatam 87% de cobertura de teste, permitindo que os desenvolvedores Java integrem com confiança a estrutura para vincular esquemas JSD(x) a seus aplicativos Java e codificar, decodificar e validar documentos JSON. Para uma visão mais detalhada da estrutura JSONx para Java, consulte JSONx Framework para Java.

Conclusão

Com um olhar mais profundo sobre a história da web e tendências de software nos últimos anos, podemos ver uma estreita relação entre a proliferação do JavaScript e a popularidade do JSON. Muitos artigos e postagens de blog oferecem uma perspectiva limitada ao comparar JSON e XML, levando os leitores a descartar o XML como obsoleto e deixando muitos inconscientes de recursos poderosos que podem ajudá-los a melhorar a arquitetura de seu software, a resiliência de seu software a mudanças e a qualidade geral e estabilidade do software como um todo. Com uma avaliação mais profunda dos pontos fortes e fracos de cada padrão, os desenvolvedores podem ser capacitados para tomar melhores decisões para seus projetos.

Como a “catástrofe de divergência” com o HTML que levou à invenção do XML, um efeito semelhante é realizado em bases de código complexas que dependem de JSON para troca de dados. A especificação JSON não encapsula as funcionalidades imediatas que envolvem o intercâmbio de dados, o que pode levar à fragmentação da lógica nas camadas superiores do aplicativo. Com o XML, no entanto, os desenvolvedores podem empurrar a complexidade que envolve o intercâmbio de dados para as camadas inferiores do aplicativo, resultando na capacidade de detectar bugs mais cedo no ciclo de vida do aplicativo. Especialmente para linguagens compiladas, em combinação com uma estrutura de vinculação, as arquiteturas que dependem da vinculação XML podem reduzir o potencial de erro relacionado a dados próximo a zero. Para a empresa, são esses recursos poderosos na redução sistemática do risco de software que tornam o XML o “santo graal da computação”.

O JSON veio para ficar, e vários projetos estão ganhando força para oferecer os poderosos recursos de XML para JSON. O projeto de esquema JSON oferece uma especificação de esquema desenvolvida pela comunidade que cresceu organicamente para oferecer suporte a uma ampla variedade de atributos e padrões declarativos para descrever e restringir documentos JSON. O projeto JSONx oferece uma linguagem de esquema de nível empresarial projetada em grande semelhança com a linguagem de definição de esquema XML e oferece formatos JSON e XML para a especificação de documentos de esquema JSON. Com essas especificações e estruturas, os desenvolvedores podem reduzir o risco de software relacionado a requisitos de camada superior em torno do intercâmbio de dados, como contratos orientados ao consumidor, controle de versão de protocolo, validação de conteúdo e muito mais.

Os recursos avançados do XML foram projetados para mitigar o risco de software relacionado às linguagens de marcação. Os casos de uso com JSON não são diferentes, e uma linguagem de esquema é uma solução testada e comprovada para proteger sistematicamente a ampla gama de riscos de software em torno do intercâmbio de dados.

Referências

1. JSON x XML (w3schools.com, dezembro de 2016)

2. O sucesso mundial que é XML (W3C, julho de 2018)

3. W3C - O que é um esquema XML? (W3C, outubro de 2009)

4. A Internet: Uma Enciclopédia Histórica. Cronologia, Volume 3, p. 130 (ABC-CLIO, 2005)

5. Esquema JSON (julho de 2008)

6. Validador de esquema JSON (GitHub)

7. JsonSchema e Subclassing (Horne, março de 2016)