Sucesso (200 ou 201)
Se você já trabalhou com algum cliente HTTP, você sabe que o status code “200” significa sucesso. GitHub irá responder com o status code 200 quando seu pedido a URL e parâmetros estiverem corretos. Se você pedir um conteúdo ao servidor, então você irá receber o status code 201, indicando o sucesso na criação do servidor.
No programa Insomnia coloque no get a chamada https://api.github.com. Veja que o status da resposta é 200.

JSON Incorreto (400)
Se seu payload (o JSON que foi enviado como pedido) é inválido, a API GitHub irá responder com o erro 400. Em -u coloque o seu nome de usuário do GitHub, no meu caso é blackzig.

Tentamos gerar um novo gist para utilizar o endpoint descrito na documentação API Gist. O erro aconteceu porque nós não utilizamos JSON. O payload foi enviado utilizando a chave -d.
GitHub responde com conselhos para olhar a documentação para saber o formato correto na documentation_url key dentro da resposta JSON. Veja que usamos a chave -X POST e passou o valor para o cURL fazer o pedido para o GitHub.
JSON Impróprio (422)
Se qualquer campo do seu pedido for inválido, o GitHub irá responder com o erro 422. A documentação indica como o payload JSON deve ser:
{
“description”: “the description for this gist”,
“public”: true,
“files”: {
“file1.txt”: {
“content”: “String file contents”
}
}
}
O que acontece se o JSON for válido, mas com algum campo incorreto?
Fiz a chamada de POST com o endereço https://api.github.com/gists e utilizando Basic no programa Insomnia.


Veja a resposta.

Há duas coisas importantes nessa situação: se voltou o erro 422, indica que o JSON é válido, mas os campos estão incorretos. A resposta indica o motivo: não encontramos o arquivo chave dentro do pedido do payload.
Criado com Sucesso (201)
O que acontece se o JSON for inválido, mas para o pedido o JSON é válido? Utilizando o Insomnia:


Sucesso! Criamos um gist e conseguimos o status code 201 indicando que tudo deu certo.
Nada Mudou (304)
O código 304 é parecido com o código 200, eles dizem ao cliente: sim, seu pedido foi processado com sucesso. Eles dão um pouco mais de informações, contudo, ele diz ao cliente que os dados não foram mudados desde o último pedido.
Essa informação é valiosa se você está preocupado com seu limite de uso (que não é o nosso caso). Não explicamos como os limites funcionam, então vamos ver como isso funciona para depois voltar para o código 304.
Fonte: Building Tools with GitHub: Customize Your Workflow (English Edition)
Deixe um comentário