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)