XML

O que é XSLT?

XSLT ou XSL Transformations (Linguagem de Folhas de estilo Extensível para Transformações) é uma linguagem de marcação XML que é utilizada para criar documentos XSL.

Documentos XSL (XSL é abreviação de eXtensible Stylesheet Language (Linguagem de Folha de Estilos Extensível)) definem a apresentação dos documentos XML nos browsers e outros aplicativos que os suportem.

Há casos em que precisamos exibir o conteúdo de arquivos XML em outros dispositivos, seja por meio de páginas HTML ou até XHTML. Nestes casos, precisamos capturar os dados existentes nos arquivos XML e enviá-los para outros formatos. É como se usássemos o arquivo XML como um banco de dados para gerar um arquivo HTML.

Para este processamento podemos utilizar o XSLT, que irá capturar os dados do arquivo XML a fim de exibi-los em um arquivo HTML, por exemplo.

XSLT Completo
Curso de XSLT Completo
CONHEÇA O CURSO

Como funciona o XSLT

Basicamente, quando precisamos exibir o conteúdo de um arquivo XML e transformá-lo em um arquivo HTML, utilizamos uma série de comandos que irá interpretar a hierarquia do arquivo XML e transformá-lo em dados para um arquivo HTML.

O XSLT, então, possui papel fundamental neste processamento, já que é ele quem vai determinar como os dados serão lidos. Basicamente, o XSLT utiliza o arquivo XML original para gerar uma árvore e a converte para uma outra árvore, porém, apenas com os dados processados, permitindo que estes sejam acessados posteriormente.

Um arquivo XSLT contém blocos que possuem expressões indicando o elemento do arquivo XML que será processado. São esses blocos que definem os dados a serem processados, como veremos no exemplo abaixo.

Transformando arquivos XML

Imagine que você precisa obter os dados de um arquivo XML e, a partir deles, criar uma página HTML para exibi-los. Com o XSLT, isso é possível e veremos abaixo como este processo funciona:

O arquivo XML utilizado para este exemplo pode ser visto abaixo, ele é, basicamente, uma coleção de dados de clientes de uma empresa:

<?xml version="1.0" encoding="ISO-8859-1"?>
<catalog>
    <cd>
        <nome>José Augusto</nome>
        <profissao>Programador</profissao>
        <nascimento>1985</nascimento>
    </cd>
    <cd>
        <nome>Maria Laura</nome>
        <profissao>Gerente de negócios</profissao>
        <nascimento>1988</nascimento>
    </cd>
    <cd>
        <nome>Pedro Paulo</nome>
        <profissao>Corretor</profissao>
        <nascimento>1982</nascimento>
    </cd>
</catalog>

Agora precisamos acessar cada entrada do documento XML acima e, para cada uma delas, adicionar a uma tabela do arquivo HTML final. Para este processamento, utilizamos o código XSLT abaixo:

<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
  <html>
  <head>
    <title>Lista de clientes</title>
    </head>
  <body>
  <h2>Clientes</h2>
    <table border="1">
      <tr bgcolor="#9acd32">
        <th>Nome</th>
        <th>Profissão</th>
        <th>Nascimento</th>
      </tr>
      <xsl:for-each select="catalog/cd">
      <tr>
        <td><xsl:value-of select="nome"/></td>
        <td><xsl:value-of select="profissao"/></td>
        <td><xsl:value-of select="nascimento"/></td>
      </tr>
      </xsl:for-each>
    </table>
  </body>
  </html>
</xsl:template>
</xsl:stylesheet>

O código XSLT acima irá percorrer a lista de dados do arquivo XML utilizando o comando for-each a partir da coleção obtida das tags cagalog/cd do arquivo XML. Para cada entrada presente nesta coleção, adicionamos a uma entrada da tabela do arquivo HTML utilizando o comando value-of select e informando qual campo queremos exibir naquele <td>. Como resultado deste processamento, teremos o seguinte código HTML:

<html>
   <head>
      <title>Lista de clientes</title>
   </head>
   <body>
      <h2>Clientes</h2>
      <table border="1">
         <tr bgcolor="#9acd32">
            <th>Nome</th>
            <th>Profissao</th>
            <th>Nascimento</th>
         </tr>
         <tr>
            <td>José Augusto</td>
            <td>Programador</td>
            <td>1985</td>
         </tr>
         <tr>
            <td>Maria Laura</td>
            <td>Gerente de negócios</td>
            <td>1988</td>
         </tr>
         <tr>
            <td>Pedro Paulo</td>
            <td>Corretor</td>
            <td>1982</td>
         </tr>
      </table>
   </body>
</html>

Com isso, utilizamos o conteúdo do arquivo XML e, com o XSLT, populamos a tabela de clientes da nossa página HTML.

Conclusão

Como vimos neste artigo, o XSLT é muito útil quando precisamos utilizar os dados contidos em um arquivo XML para exibí-los em um outro formato. É uma espécie de linguagem de consulta de arquivos XML, muito utilizada em empresas que possuem arquivos enormes de XML com dados que precisam ser exibidos de uma forma mais “amigáveis”.

O que é YAML?

Lançada em 2001 e inspirada em linguagens como XML, Python, C, entre outras, YAML ou, acrônimo recursivo para “YAML Ain’t Markup Language” é um formato de serialização de dados legível por humanos, sendo bastante utilizado para arquivos de configuração, assim como o JSON e o XML.

Xamarin.Forms - Primeiros passos
Curso de Xamarin.Forms - Primeiros passos
CONHEÇA O CURSO

Possui uma sintaxe simples e legível, podendo ser mapeada facilmente pelos tipos de dados mais comuns na maioria das linguagens de alto nível, sendo criada especificamente para funcionar bem em casos de uso comum, como, por exemplo:

  • Arquivos de configuração;
  • Compartilhamento de dados entre linguagens;
  • Depuração de estruturas de dados complexas;
  • Mensagem entre processos, entre outros.

Baseada em indentação, é uma linguagem que possui bastante similaridade ao XML e ao JSON que já falamos sobre em artigos anteriores.

Pode ser facilmente implementada em linguagens como:

Principais características

Além da sua familiaridade com XML, possui como principais características:

  • Utilizam um conjunto de caracteres unicode (UTF-8 ou UTF-16);
  • Possui propósito centrado em dados no lugar de documentos marcados;
  • Case sensitive;
  • Pode ser utilizada por diversas linguagens;
  • É mais legível que o XML e JSON;
  • Possui excelente documentação, entre outros.

Sintaxe

A sintaxe do YAML é extremamente simples e legível, como podemos verificar abaixo:

funcionario:
 nome: João
 idade: 30
 sexo: Masculino
 profissao: Programador
  dependente:
   nome: Maria
   sexo: Feminino

Conforme visto acima, o YAML permite estruturas os dados de maneira bem simples. No exemplo anterior, determinamos os atributos de um funcionário (nome, idade, sexo e profissâo), além de uma relação com um dependente, que também possui seus atributos (nome e sexo).

Em JSON, a estrutura acima pode ser vista de seguinte forma:

{
"funcionario": { 
    "nome": "João", 
    "idade": 30,
    "sexo": "Masculino",
    "profissao":  "Programador",
        "dependente": {
            "nome": "Maria", 
            "sexo": "Feminino"
        } 
    } 
}
Google Cloud - Primeiros Passos
Curso de Google Cloud - Primeiros Passos
CONHEÇA O CURSO

Podemos concluir que…

O YAML é, também, uma ótima alternativa para armazenar e estruturar dados a serem transferidos entre diversos sistemas. Possui uma sintaxe mais limpa e legível que seus principais “concorrentes”, o XML e o JSON e pode ser utilizado em diferentes linguagens de programação.

Desenvolvedor Python Pleno
Formação: Desenvolvedor Python Pleno
Aprenda como trabalhar com banco de dados relacionais em aplicações Python utilizando a DB API e o MySQL.
CONHEÇA A FORMAÇÃO

JSON vs XML

Anteriormente falamos a respeito de o que é JSON e o que é XML.

Para relembrarmos, caso ainda não tenha lido os artigos anteriores, vamos a um breve resumo:

JSON

JSON é um acrônimo de “Javascript Object Notation” ou simplesmente “Notação de objeto JavaScript”. É um modelo para a transmissão de informações no formato de texto entre diferentes linguagens, ou seja, é um formato de serialização de dados muito utilizado em web services.

Dentre suas diversas características, a mais atrativa sem dúvidas é a sua legibilidade, podendo facilmente ser lido por humanos, sem a necessidade de uma aplicação auxiliar.

XML

Extensible Markup Language, ou simplesmente XML, é uma linguagem de marcação, ou seja, um conjunto de códigos para determinar a estrutura de dados para facilitar a troca de informação entre sistemas computacionais, lançado na década de 90 pela W3C (World Wide Web Consortium – órgão responsável pela definição da linguagem XML e pela padronização de outras iniciativas ligadas à Web).

Além de ser facilmente lido sem o auxílio de qualquer software e ser responsável por prover uma língua “universal” para troca de informação entre aplicações, o XML possui como vantagens a fácil distribuição na Web, integração de dados de fontes diferentes, buscas mais eficientes, desenvolvimento de aplicações web flexíveis, entre outros.

XML Completo
Curso de XML Completo
CONHEÇA O CURSO

JSON vs XML

Junto com a grande crescente do JavaScript dos últimos anos, o JSON se consolidou cada vez mais, aperfeiçoando sua tecnologia. Com isso, grandes vantagens que o XML possuía em relação ao JSON foram caindo aos poucos. Exemplo disso são os XML Schemas e o XSLT, por exemplo, que possuem equivalentes no JSON (JSON Schema e JOLT).

Além disso, a adoção das principais linguagens de desenvolvimento com o JSON foi outro ponto crucial nessa crescente. Hoje, várias linguagens de desenvolvimento já possuem bibliotecas para uso do JSON, como C++, Python, Perl, PHP, R e diversas outras.

Com todas essas vantagens, é fácil afirmar que o JSON “matou” o XML, certo?

Bom, não…

Apesar de ser um pouco mais difícil de ser lido que o JSON e, em alguns casos, mais complicados de integrar, o XML é, sim, uma tecnologia forte. Grande parte dessa força está em sua comunidade, que ainda permanece ativa e com diversos membros, afinal, uma tecnologia tão grande assim não desaparece tão rapidamente, né?

Além disso, o XML é a tecnologia preferida para trabalhar com metadados, capaz de guardar ou vincular dados em qualquer formato, justamente pela liberdade dada ao usuário em definir as marcações que compõem um objeto.

E ai, qual usar?

Como em tudo na tecnologia, não há certo ou errado. O XML e o JSON são ótimas ferramentas para transporte de informações entre diferentes aplicações. Engana-se quem acha que o XML “morreu” pelo JSON.

Apesar de ser mais popular e, nos principais casos, mais rápido, o JSON ainda não consegue trabalhar tão bem com dados mais complexos como o XML faz.
Sendo assim, antes de decidir usar o JSON ou XML, é sempre bom estudar um pouco seu projeto e analisar qual a melhor alternativa. Com certeza, uma das duas vai servir muito bem. 🙂

O que é XML?

Lançado na década de 90 e desenvolvido pela W3C (World Wide Web Consortium – Organização responsável pela definição da linguagem XML e pela padronização de outras iniciativas ligadas à Web), Extensible Markup Language, ou simplesmente XML, é uma linguagem de marcação, ou seja, um conjunto de códigos para determinar a estrutura de dados para facilitar a troca de informação entre sistemas computacionais.

Para que serve o XML?

Como dito anteriormente, a principal finalidade do XML é auxiliar a troca de informações entre sistemas (principalmente via internet). Principal concorrente do JSON, o XML permite que diferentes tipos de sistemas possam trocar dados, independente de sua linguagem de desenvolvimento.

Uma das suas principais características é também sua portabilidade, pois desta forma os seus dados poderão ser compartilhados entre diferentes aplicações.

XML Completo
Curso de XML Completo
CONHEÇA O CURSO

Como sabemos, com o passar do tempo, o modo com que os sistemas são desenvolvidos mudou. Atualmente, é bem comum que determinados dados sejam compartilhados por diversas aplicações. Para este propósito, o uso de web services tem se tornado cada dia mais relevante, pois são com eles que conseguimos criar um serviço para que diversas aplicações clientes consumam o mesmo banco de dados. E é aí que o XML entra, pois é com ele que determinamos uma língua “universal” para esta troca de informação.

Estrutura do XML

A estrutura do XML é relativamente simples. Basicamente, suas tags definem o que caracteriza um determinado objeto no sistema (atributos) e seus valores.

Por exemplo, imagine que queremos compartilhar dados de um contato utilizando o XML e este contato é formado pelo nome, email e telefone. Com o XML, o contato seria representado da seguinte forma:

<?xml version="1.0"?>
<contato>
    <nome>Ana Paula de Andrade</nome>
    <email>anapaula@mail.com</email>
    <telefone>
        <ddd>77</ddd>
        <numero>123456789</numero>
    </telefone>
</contato>

Todas as “tags” devem ser fechadas e os nomes dos elementos e dos atributos são sensíveis à caracteres minúsculos e maiúsculos.

Podemos notar o quão simples e legível é um objeto em XML. Sem o auxílio de qualquer ferramenta, conseguimos, facilmente, identificar do que se trata o código XML acima e quais dados ele representa, separados por tags entre os símbolos “.

Vantagens do XML

Além de ser facilmente lido sem o auxílio de qualquer software e ser responsável por prover uma língua “universal” para troca de informação entre aplicações, o XML possui outras vantagens:

  • Fácil distribuição na Web;
  • Integração de dados de fontes diferentes;
  • Buscas mais eficientes;
  • Desenvolvimento de aplicações web flexíveis;
  • Escalabilidade;
  • Compressão.
  • Capacidade de guardar ou vincular dados em qualquer formato, entre outros.

Concluindo

O XML é um ótimo meio para troca de informações entre diferentes aplicações, assim como o JSON. Porém, cada uma destas tecnologias possuem seu público alvo e vantagens. Não sabe qual utilizar? É exatamente isso que discutiremos no artigo JSON vs XML 🙂

Desenvolvedor React Native Júnior
Formação: Desenvolvedor React Native Júnior
O React Native nos permite criar aplicativos mobile realmente nativos com JavaScript para Android e iOS. Ele vem sendo usado em aplicativos como Facebook, Instagram e Uber.Nesta formação vamos iniciar nossos estudos em React Native e depois aprender a acessar APIs nativas, incluindo o desenvolvimento de nosso próprio código nativo (Java e Objective-C) e integrá-lo ao JavaScript.
CONHEÇA A FORMAÇÃO

REST não é simplesmente retornar JSON: indo além com APIs REST

É até comum, de certa forma, ouvirmos alguém falar que construiu uma API REST porque acabou disponibilizando um endpoint que retorna alguma informação no formato JSON. Mas isso, infelizmente, é um equívoco. Criar uma API REST nada tem a ver com simplesmente retornar algum JSON.

Neste post, vamos discutir sobre os conceitos de REST e JSON e verificar que, apesar de serem conceitos muito íntimos hoje, tecnicamente um não não tem nada a ver com o outro.

HTTP - Fundamentos
Curso de HTTP - Fundamentos
CONHEÇA O CURSO

Mas, afinal de contas, o que é REST?


Hmmm, pelo jeito é algo arquitetural…

REST é um acrônimo para REpresentational State Transfer, ou seja, Transferência de Representação de Estado. O REST é, no final das contas, um estilo arquitetural que podemos utilizar ou não em nossas aplicações.

O conceito do REST foi criado pelo norte-americano Roy Fielding. Roy é também um dos principais responsáveis pela especificação técnica do protocolo HTTP. Sim, esse mesmo protocolo que você está utilizando nesse exato momento para visualizar esta página em nosso blog. A idéia do REST é utilizar de maneira mais eficiente e em sua plenitude as características do protocolo HTTP, principalmente no que diz respeito à semântica do protocolo. O resultado disso ao final das contas é, além da utilização mais “correta” do protocolo, um trânsito de informações mais eficiente e, por consequência, mais rápido.

Mas quais são as características do protocolo HTTP?

O protocolo HTTP, por decorrência de sua arquitetura, possui algumas características bem marcantes:

  • É um protocolo cliente-servidor: o protocolo HTTP se caracteriza por uma conexão feita entre uma máquina cliente e uma máquina servidora. Quando você acessa o nosso blog, por exemplo, você está fechando uma via de comunicação entre a sua máquina com o nosso servidor. É através dessa conexão que seu browser baixa o HTML, o CSS, o JavaScript e as imagens necessárias para renderizar a página solicitada;

  • A comunicação entre o cliente e o servidor é feita através de “mensagens HTTP”: o tráfego de dados entre um cliente e um servidor é feito através de porções de informação chamadas mensagens. Em uma “rodada” de comunicação, nós temos duas mensagens envolvidas: a mensagem enviada pelo cliente solicitando algo, chamada de request; e a resposta do servidor para a solicitação realizada, chamada de response. Estes dois componentes são essenciais para que a comunicação ocorra seguindo o protocolo HTTP e não é possível ter um request sem que depois haja um response e vice-versa;

  • O protocolo HTTP por definição não é “keep alive”: por padrão, uma conexão HTTP só dura até o momento em que o ciclo request-response é concluído. Logo após este ciclo, a conexão é automaticamente encerrada, ou seja: a conexão morre. Caso algum novo conteúdo precise ser trafegado entre o cliente e o servidor, uma nova conexão é aberta. Hoje, até existe maneiras de se modificar esse comportamento utilizando-se algumas flags na requisição (uma destas flags se chama justamente keep-alive), mas é importante destacar que o protocolo originalmente não foi planejado para essa finalidade;

  • O protocolo HTTP é utilizado de maneira assíncrona na maioria dos clientes: requisições HTTP são assíncronas por definição do lado dos clientes. Isso quer dizer que, se você precisa disparar duas requisições para baixar dois conteúdos distintos, o cliente pode disparar essas requisições ao mesmo tempo, sendo que cada uma delas pode ser respondida em um tempo diferente. O protocolo HTTP foi concebido para funcionar desta forma. Inclusive, quando você renderiza uma página, você pode verificar este comportamento observando a aba “Network” do Web Inspector se você utiliza browsers baseados no WebKit/Blink, como o Chrome:

Na figura acima, temos a inspeção do carregamento da página inicial do nosso blog. Cada um dos componentes listados abaixo do gráfico representa um componente que foi solicitado ao servidor, ou seja: houve um ciclo de requisição HTTP para a obtenção de cada um daqueles componentes, sendo que cada ciclo deste foi transmitido dentro de uma conexão própria ao servidor. O gráfico acima mostra o momento que a requisição foi disparada, bem como quanto tempo o servidor demorou para devolver a response correspondente.

Veja que no gráfico acima, podemos notar que o browser dispara várias requisições ao mesmo tempo, sendo que cada uma tem sua resposta em seu devido tempo. Isso prova que o protocolo HTTP é tratado de maneira assíncrona. Esse processo, inclusive, é chamado de pipelining.

Se você já lidou com AJAX por exemplo, já deve ter ouvido falar sobre o termo callback. Nós precisamos apelar para callbacks (ou promisses ou observables) justamente por causa desta característica do protocolo HTTP: nós precisamos de uma resposta do servidor, mas, pelo cliente fazer a requisição de maneira assíncrona, nós não sabemos exatamente quando essa resposta vai chegar… Por isso criamos callbacks (ou promisses ou observables) para serem executados quando o ciclo request-response for finalmente concluído.

  • As conexões no protocolo HTTP são independentes: como as conexões são abertas e fechadas a medida que algum conteúdo precisa ser trafegado, as conexões acabam sendo independentes umas das outras. Junto à característica assíncrona do protocolo HTTP, isso torna tecnicamente inviável que uma conexão possa “se comunicar” com alguma outra que esteja em curso, ou mesmo conhecer quais outros ciclos request-response estão em curso em determinado momento;

  • O protocolo HTTP é “stateless”: por decorrência dos três últimos pontos, nós afirmamos que o protocolo HTTP é stateless, ou seja, ele não guarda estado das requisições. Mais uma vez, isso é inviável, já que as conexões HTTP são independentes, assíncronas e, principalmente, por não serem keep alive. Se a conexão é imediatamente fechada após sua utilização, como podemos guardar alguma informação sobre ela? É exatamente por essa característica do protocolo HTTP que acabamos utilizando técnicas (como os cookies) para tentar guardar alguma informação necessária, como o usuário que está logado em uma aplicação por exemplo.

  • O protocolo HTTP é semântico: os recursos que podem ser disponibilizados por um servidor HTTP (como um página, por exemplo) podem ser acessados através de URIs (Unique Resource Identifier), que podem ser “traduzidas” para URLs (Unique Resource Locator). O grande ponto é que um servidor Web pode disponibilizar não somente páginas, ele também pode, por exemplo, fazer um upload de um arquivo. Para traduzir o que deve ser feito no servidor, o protocolo HTTP disponibiliza algo que nós chamamos de verbo ou método HTTP. A idéia é que esse verbo, associado ao request, indique o que deve ser feito no servidor.

Nós temos vários verbos HTTP, mas os principais, de maneira sucinta, são:

1) GET: indica que um recurso será recuperado do servidor. Por exemplo, quando você solicita uma página pelo seu browser;

2) POST: indica que um recurso será inserido ou criado no servidor. Um upload de um novo arquivo, por exemplo;

3) PUT: indica que um recurso será atualizado no servidor. Seria equivalente a um update em uma base de dados;

4) DELETE: indica que um recurso será removido do servidor. Seria o equivalente a um delete em uma base de dados.

Isso quer dizer que nós podemos invocar uma mesma URL (ou URI) em uma requisição HTTP, porém, dependendo da atribuição do verbo HTTP, a requisição irá desempenhar uma tarefa diferente no servidor. O verbo HTTP acaba determinando a semântica – ou significado/intenção – da requisição HTTP.

E o JSON? Onde ele entra na jogada?

O JSON (JavaScript Object Notation) não é um protocolo de transporte de informações como o HTTP. Ele é somente uma forma bem leve de representação e troca de informações. Ele tem a única função de levar informações de um lado para o outro. Nós podemos utilizar o JSON para transportar informações entre mensagens HTTP.

JSON x XML


Mas calma! A “treta” não precisa começar, rs

O XML também é uma forma de representação de informações. Porém, é uma forma mais “pesada” e verbosa de representação, já que preza pela “legibilidade” das informações a serem representadas.

Veja, por exemplo, um fragmento de um XML:

<clientes>
    <cliente>
        <id>1</id>
        <nome>TreinaWeb Cursos</nome>
        <idade>10</idade>
    </cliente>
</clientes>

A mesma informação acima poderia ser representada facilmente com o JSON abaixo:

"clientes" : [
    {
        "id" : 1,
        "nome" : "TreinaWeb Cursos",
        "idade" : 10
    }
]

Veja que, apesar de não ser tão explícita, a forma de representação com o JSON é muito mais direta e simples do que através do XML. Perceba também a quantidade de caracteres utilizados em cada uma das representações… Isso é um ponto muito importante! Como o JSON utiliza menos caracteres que o XML, ele também vai ocupar menos bytes dentro de um response com relação ao XML e, por consequência, o download de um response que contenha dados no formato JSON será mais rápido do que um response com as mesmas informações no formato XML. Essa é uma das principais justificativas para os desenvolvedores preferirem utilizar JSON do que XML para o intercâmbio de informações.

Então, o REST e o JSON possuem responsabilidades completamente diferentes!?


Me desculpa se isso foi um balde de água fria… 🙁

Sim, exatamente esse é o ponto! REST é um conceito arquitetural muito complexo, mas que no fim visa tirar vantagem de todas as características do protocolo HTTP, que é um protocolo de transporte. O JSON é somente uma forma de representar informações que precisam ser transportadas de um lado para outro. Sendo assim, podemos utilizar o protocolo HTTP para fazer o transporte de dados entre um cliente e um servidor.

Para conseguir utilizar o protocolo HTTP da forma correta, nós podemos adotar uma arquitetura baseada no REST. Agora, para fazer a representação das informações que precisam ser transportadas através do protocolo HTTP em uma arquitetura REST, nós podemos utilizar o JSON.

Mas então, eu posso ter uma API REST que responde XML?


Isso pode ser interessante…

Absolutamente, sim! Você, neste caso, só estará alterando a forma como as informações serão representadas nas requisições HTTP. Lembre-se: as responsabilidades do HTTP, do REST, do JSON e do XML são completamente diferentes. Isso, inclusive, é um trunfo da arquitetura REST: a representação das informações e o modo de transporte destas são completamente desacopladas.

Inclusive, é muito comum que APIs aceitem dados tanto no formato XML quanto no formato JSON, além de também responderem nestes dois formatos. As linguagens modernas hoje praticamente oferecem suporte nativo ao formato JSON, o que faz com que a adoção deste seja mais popular. Mas muitos sistemas, principalmente os sistemas legados, ainda são fundamentados no formato XML. Por isso é interessante que as APIs respondam nos dois formatos. Inclusive, as APIs definem a forma como vão fazer a leitura das informações com base no formato com que estas estão representadas, bem como definem o formato de dados a ser utilizado para a resposta, em uma etapa chamada content negociation.

“Perceba a petulância do protocolo HTTP!”


Do clássico meme “Percebe, Ivair, a petulância do cavalo!”

E ele é petulante com muita razão, haha. Afinal, toda a web hoje é fundamentada nele. Qualquer transporte de informação que for necessário entre aplicações hoje em dia passará pelo HTTP. Perceba como as características dele justificam muitas coisas que nós sem querer fazemos no automático quando estamos desenvolvendo soluções baseadas na Web.

Eu costumo dizer que entender os princípios básicos do protocolo HTTP é importantíssimo para qualquer desenvolvedor Web hoje em dia. Quando o desenvolvedor sabe como que as coisas “funcionam por baixo dos panos”, ele se preocupa mais com a maneira como ele vai desenvolvedor, além de entender bem melhor o porquê de algumas coisas serem do jeito que são.

Agora, deixa eu aproveitar o momento para fazer um “jabá”, hahaha: sabia que temos aqui no TreinaWeb um curso sobre o protocolo HTTP? Se você se interessar:

HTTP - Fundamentos
Curso de HTTP - Fundamentos
CONHEÇA O CURSO

© 2004 - 2019 TreinaWeb Tecnologia LTDA - CNPJ: 06.156.637/0001-58 Av. Paulista, 1765, Conj 71 e 72 - Bela Vista - São Paulo - SP - 01311-200