JAVASCRIPT OBJECT NOTATION - JSON

                                   

JavaScript Object Notation, é um formato padrão aberto que usa texto legível para transmitir objetos de dados que consistem em pares de valores de atributo.

 É utilizado principalmente para transmitir dados entre um servidor e aplicação da web, como uma alternativa para XML.

Embora originalmente derivada da linguagem de script JavaScript, JSON é um formato de dados independente de linguagem, e codifica para analisar e gerar dados JSON está prontamente disponível em uma grande variedade de linguagens de programação.

 A extensão do arquivo JSON é. Json.

Tipos de Dados

Tipos básicos de JSON são:

• Number (dupla precisão formato de ponto flutuante )
• String (entre aspas Unicode, com barras de escape)
• Boolean (true ou false)
• Array (, uma seqüência separada por vírgula ordenada de valores entre colchetes; os valores não precisam ser do mesmo tipo)
• Object (uma coleção não-ordenada, separada por vírgulas de chaves)
• null (vazio)

Espaço em branco não significativos podem ser adicionados livremente em torno dos "caracteres estruturais" (ou seja, chaves, colchetes "{} []", dois pontos ":" e vírgulas ",").

O exemplo a seguir mostra a representação JSON de um objeto que descreve uma pessoa. O objeto tem campos string para o primeiro nome e sobrenome, um campo de número para a idade, um objeto que representa o endereço da pessoa e uma array de objetos telefone.

{
    "primeiroNome": "João",
    "ultimoNome": "Ferreiro",
    "idade": 25,
    "endereco": {
        "rua": "rua Austero Penteado 115",
        "cidade": "Campinas",
        "estado": "SP",
        "codigoPostal": 13020 320
    },
    "telefoneNumeros": [
        {
            "tipo": "casa",
            "numero": "19 3239-0751"
        },
        {
            "tipo": "fax",
            "numero": "19 3239-0751"

        }
    ]
}

Uma armadilha potencial da natureza de forma livre de JSON vem da capacidade de escrever números tanto como números literais quanto strings citadas.

 Por exemplo, os CEP no nordeste dos EUA começam com zeros (por exemplo, 07728 para Freehold, Nova Jersey). Se escrito como strings por um programador, mas não por outro, o zero poderia ser descartado quando a string fosse trocada entre sistemas, quando procurada dentro do mesmo sistema, ou quando impressa.

 Além disso, os códigos postais em os EUA são números, mas em outros países usam letras também. Este é um tipo de problema que o uso de um esquema JSON (ver em baixo) destina-se a reduzir.

Uma biblioteca parser JSON ou suporte JSON nativo do Javascript deve ser usado para leitura e escrita JSON. Um analisador JSON corretamente implementado aceita apenas JSON válido, impedindo códigos potencialmente maliciosos sejam executados de forma inadvertida.

var p = JSON.parse(contact);

Os navegadores da Web, desde 2010, incluiram suporte para analisar JSON. Como suporte ao navegador nativo é mais eficiente e seguro do que o eval (), suporte nativo a JSON está incluído na edição 5 do padrão ECMAScript.

A biblioteca jQuery envolve um objeto JSON em um construtor de função e executa-o imediatamente se JSON.parse não está presente. Isto evita o uso de eval no código.

 var p = new Function('return ' + contact + ';')();

Tipos de Dados Nativos Não Suportados

JavaScript sintaxe define vários tipos de dados nativos que não estão incluídos no padrão JSON :  Datas, erros, expressão regular, e função.

Estes tipos de dados JavaScript devem ser representados como algum outro formato de dados, com os programas em ambas as extremidades concordando sobre como fazer a converção entre os tipos.

Desde 2011, existem alguns padrões de eventos, por exemplo conversão entre Datas e Strings, mas nenhum universalmente reconhecida.

Outras linguagens podem ter diferentes conjuntos de tipos nativos, que devem ser serializados com cuidado para lidar com este tipo de conversão.

Esquemas e Metadados

Características do Esquema JSON:

Especifica um formato baseado em JSON para definir a estrutura de dados JSON para validação, documentação e controle de interação. 

Fornece um contrato para os dados JSON exigidos por uma determinada aplicação, e como esses dados podem ser alterados.

Embora baseando-se nos conceitos de esquemas XML, é um fundamento JSON próprio,  de modo que os dados JSON sob a forma de um esquema pode ser utilizado para validar dados JSON, as mesmas ferramentas de serialização/desserialização podem ser utilizadas para o esquema e dados, e é auto-descritivo .

Exemplo de Esquema JSON:

{
    "name": "Product",
    "properties": {
        "id": {
            "type": "number",
            "description": "Product identifier",
            "required": true
        },
        "name": {
            "type": "string",
            "description": "Name of the product",
            "required": true
        },
        "price": {
            "type": "number",
            "minimum": 0,
            "required": true
        },
        "tags": {
            "type": "array",
            "items": {
                "type": "string"
            }
        },
        "stock": {
            "type": "object",
            "properties": {
                "warehouse": {
                    "type": "number"
                },
                "retail": {
                    "type": "number"
                }
            }
        }
    }
}

O esquema JSON abaixo pode ser usado para teste de validação do código acima:

{
    "id": 1,
    "name": "Foo",
    "price": 123,
    "tags": [ "Bar", "Eek" ],
    "stock": {
        "warehouse": 300,
        "retail": 20
    }
}

RPC 

Uma Chamada de Procedimento Remoto (RPC) é uma comunicação entre processos que permite a um programa de computador executar uma sub-rotina ou procedimento em outro endereço (geralmente em outro computador em uma rede compartilhada) sem que o programador tenha codificado explicitamente os detalhes sobre a interação remota.

Isto é, o programador escreve essencialmente o mesmo código quer a sub-rotina seja para execução local do programa, ou para execução remota.

 Quando o software em questão utiliza princípios de orientação a objetos, RPC é chamado de invocação remota ou invocação de método remoto.

Envio de Mensagens

Uma RPC é iniciada pelo cliente, que envia uma mensagem de requisição para um servidor remoto conhecido para executar um procedimento especificado com parâmetros fornecidos.

 O servidor remoto envia uma resposta para o cliente, e o aplicativo continua o seu processo.

 Enquanto o servidor está processando a chamada, o cliente é bloqueado (ele espera até que o servidor tenha terminado o processamento antes de retomar a execução), a não ser que o cliente envie uma solicitação assíncrona para o servidor, como uma chamada XHTTP.

 Há muitas variações e subtilezas em várias implementações, resultando numa variedade de diferentes (incompatíveis) protocolos RPC.

Uma diferença importante entre chamadas de procedimento remoto e chamadas locais é que as chamadas remotas podem falhar por causa de problemas imprevisíveis de rede.

 Além disso, os chamadores geralmente tem que lidar com essas falhas sem saber se o procedimento remoto foi aceito, ou se teve a requisição compilada.

 Procedimentos idempotentes (aqueles que não têm efeitos adicionais se for chamado mais de uma vez) são facilmente manipulados, mas muitas dificuldades permanecem onde o código para chamar procedimentos remotos é muitas vezes confinado um a escrita cuidadosa em subsistemas de baixo nível.

Seqüência de eventos durante uma RPC

1. O cliente chama o stub (um trecho do código usado para conversão de parâmetros passados durante uma RPC) do cliente. A chamada é um de procedimento de chamada local, com parâmetros colocados em pilha de uma forma normal.
2. O stub do cliente empacota os parâmetros em uma mensagem e faz uma chamada para o sistema enviar a mensagem. Empacotar dos parâmetros é chamado de  marshalling ( serialização - processo de conversão de dados ou objetos em um fluxo de bytes ).
3. Sistema operacional local do cliente envia a mensagem a partir da máquina do cliente para a máquina do servidor.
4. O sistema operacional na máquina do servidor repassa os pacotes da entrada para o stub do servidor.
5. O stub do servidor desempacota os parâmetros da mensagem. Desempacotando os parâmetros é chamado unmarshalling (deserialização - processo inverso de conversão de um fluxo de bytes de volta a seus dados ou objetos originais).
6. Finalmente, o stub do servidor chama o procedimento servidor do sistema operacional. A resposta segue os mesmos passos na direção inversa.

Padronização dos Mecanismos de Contato

Para permitir que diferentes clientes acessem os servidores, foram criadas uma série de sistemas RPC padronizados. 

A maioria deles usa uma Linguagem de Descrição da interface (IDL) para permitir que várias plataformas possam chamar o RPC.

 Os arquivos IDL pode então ser utilizado para gerar o código de interface entre o cliente e o servidor.

JSON_RPC

É um protocolo RPC (Remote Procedural Call) construído em JSON, como um substituto para o XML-RPC e SOAP, sendo um simples protocolo que define somente alguns tipos de dados e comandos. 

Em contraste ao XML-RPC ou ao SOAP, ele permite comunicação bidirecional entre o serviço e o cliente, como uma espécie de peer-to-peer, onde cada uma das pontas pode chamar a outra ou enviar notificações(informações enviadas ao servidor que não requerem uma resposta). Ele também permite o envio de múltiplas chamadas de uma ponta a outra que podem ser respondidas fora de ordem.

Uma comunicação JSON pode ser feita em uma requisição HTTP onde o conteúdo é do tipo application/json.1 Além de usar o HTTP para transporte, podem ser usados sockets TCP/IP. Usando sockets, podem ser criadas aplicações web mais responsivas com o JSON-RPC, em comparação com um simples tráfego de um serviço JSON-RPC sobre HTTP.

Abaixo há um exemplo de um JSON-RPC 2.0 com pedido e resposta usando parâmetros posicionais.

--> {"jsonrpc": "2.0", "method": "subtract", "params": [42, 23], "id": 1}
<-- {"jsonrpc": "2.0", "result": 19, "id": 1}