1.1-Desmistificando-200.md

Desmistificando o retorno 200 do Graphql

Precisamos fazer uma viagem pela história do HTML, antes de desmistificar o retorno do Graphql.

O década é de 1990, e o http (Hypertext Transfer Protocol) começa a ser difundido mundialmente.

E endereços como www.ig.com.br começam a surgir e com eles uma série de recursos podem ser acessados e interpretados por browsers.

O procotolo HTTP

Protocolo

Primeiro precisamos enteder o que é um protocolo.

Protocolo é uma camada de abstração que define um mecanismo de comunicação entre dois pontos.

Imagina que você acaba de conhecer uma pessoa na rua, você olha para ela e diz: "Olá!"

Você acabou de usar um protocolo para comunicar com a pessoa. Se ela estiver ciente do protocolo ela provavelmente vai reconhecer a mensagem e responder.

Da mesma forma funcionam os computadores, existem vários protocolos para executar diferentes tarefas.

HTTP

O protocolo utilizado para buscar recursos na web é o http (Hypertext Transfer Protocol).

Vamos pegar um recurso como exemplo:

http://api.sotops.com.br/images/nudedodaniel.jpg

E quebrá-lo em partes:

http://: Protocolo
api: Maquina no servidor
sotops: Servidor
com: nameServer comercial
br: nameServer brasileiro
images: Pasta no servidor
nudedodaniel.jpg: arquivo no servidor

Quando você acessa essa página, o browser irá buscar o recurso e enviará uma requisição para o servidor.

Primeiro procura por um servidor que seja responsável por recursos no br e lá pergunta sobre onde está o responsável por recursos comerciais.

Ao encontrar os recursos comerciais, pergunta onde está o servidor sotops.

Ao encontrar o servidor sotops, pergunta qual maquina no servidor é responsável pela api.

Ao encontrar a máquina api, requisita o arquivo nudedodaniel.jpg na pasta images.

Dentro do pacote de requisição não existe nada, apenas cabeçalhos com a informação dela em si, como o endereço de quem requisitou o recurso.

Agora imagina que algums erros podem ocorrer nessa requisição, como por exemplo:

• Ao chegar no servidor ele diz que o endereço no cabeçalho não tem autorização para acessar o recurso, então o protocolo retorna um código de resposta HTTP 403.

• Vamos supor que a pasta images existe, mas o arquivo não existe, então o protocolo retorna um código de resposta HTTP 404.

• Vamos supor que ocorre um erro no servidor, entao o protocolo retorna um código de resposta HTTP 500.

• Vamos supor que tudo ocorre bem e você consegue acessar o recurso. Então o protocolo retorna um código de resposta HTTP 200.

Por uns bons anos o protocolo http foi utilizado dessa forma, mas com o passar do tempo e a modernização do desenvolvimento web e com o advento do REST, a forma como o protocolo http foi entendi mudou.

E ele se tornou reponsável não só pelo que está em seu nome "TRANSFER", mas colocaram dentro do protocolo também tudo aquilo que podia ou não acontecer "dentro" do servidor.

E com isso o protocolo http ficou responsável não só para ser utilizado para transferir arquivos, mas também pode ser utilizado para fazer requisições ao servidor e responsável por analisar tudo aquilo que acontece internamente no servidor.

Quando por exemplo você faz um put em um usuario com email inválido, o servidor altera o protocolo e faz com que ele responda HTTP 400, ou seja, o servidor não conseguiu fazer o put do usuario com email inválido.

Se você analisar pela perspectiva de um protocolo de transferência, o mais "correto" é que ele respondesse um 200, uma vez que o protocolo não é responsável pelo conteúdo da requisição mas pela TRANSFERENCIA dela.

Quando você recebe uma pizza de calabresa na sua casa com peperoni, a responsabilidade é do entregador ou do restaurante?

O que você pode fazer é pedir que o entregador devolva a pizza para o restaurante com a mensagem de que o sabor da pizza estava incorreto.

Quando perguntado se ocorreu tudo bem ao transferir a pizza para a casa do cliente o motorista vai dizer que sim, mas que ele tem uma mensagem de que a pizza não tinha o sabor correto.

E por que isso é importante para o graphql?

Requisições graphql

Vamos usar como exemplo a requisição de usuário que temos no capítulo de conceito.

Mas dessa vez vamos utilizar requisições multiplas, ou seja, ao inves de fazer apenas uma requisição para o backend eu vou fazer duas, ao mesmo tempo.

query{
  q1:user(id: 1){
    id
    name
    post {
      id
      title
    }
  }
  q2: user(id: 2){
    id
    name
    post {
      id
      title
    }
  }

Agora imagina que o usuário de id:1 existe, mas o usuário de id:2 não. Portanto eu teria um http 200 para o primeiro e um 404 para o segundo.

E ai vem a pergunta de um milhão, qual reponse eu dou para meu cliente?

Por isso o graphql fez com que o protocolo http voltasse as suas origens e ficasse responsável apenas pela transferência de dados, não pelo conteúdo dos dados.

Pelo conteúdo dos dados a responsabilidade fica no mensagem da resposta, que normalmente feita em json.

Um exemplo de resposta:

{
  "error": {
    "q1": {},
    "q2": {}
  },
  "data": {
    "q1": {},
    "q2": {}
  }
}

Uma resposta típica graphql sempre contem um objeto com dois objetos dentro. Um deles o error responsável por dizer o que houve de errado com a requisição. E o outro data responsável pelos dados da requisição.

Dentro de cada um desses objetos poderemos ter separadamente cada uma das queries e suas respectivas respostas.

Made with 💜