API não está no padrão da RFC 7231

[davi5e]

Por algum motivo, a API da Gerencianet não está no padrão da RFC 7231 e, entre outras coisas, costuma retornar códigos de status dentro da resposta, inclusive misturando 200 do HTTP com códigos de erro customizados...

Outro problema é que o backend da Gerencianet em si só entende 200 como resposta de suscesso na URL de notificação e o status 204 No Content são considerados como erros no painel da plataforma...

A padronização da API de acordo com a RFC e possível criação de webhooks autenticados seriam ideais (podendo enviar os dados do endpoint GET /v1/charge/:id diretamente ao invés da forma atual de mandar notification).

[guilhermecotaGn]

Oi @davi5e, tudo bem? 😄
Levarei sua sugestão para a equipe analisar. Tendo uma posição, lhe dou retorno.

Desde já, obrigado!

[guilhermecotaGn]

[SDK - PHP] Verificar issue repositório GitHub (API não está no padrão da RFC 7231)

[davi5e]

Oi @guilhermecotaGn ,

Teoricamente, fazer a API compatível com a RFC exigiria parar de responder 200 quando existe um erro (atualmente no campo code). O ideal seria alguma coisa no range do 400 para indicar erro.

Outro comportamento que notei é que quando existe um problema no argumento da URL, a resposta é 500 o que teoricamente também estaria errado (não é um erro interno se a URL veio errada...).

O que mais chamou a atenção foi o servidor da Gerencianet não entender respostas 204 no webhook que envia o token.

Além disso, enviar um token para que o client insira essa informação numa chamadas subsequente poderia ser evitado se o webhook fosse autenticado. Parece já ser assim na API do PIX, por exemplo. Nossa solução foi assinar a URL do webhook para garantir que apenas a Gerencianet consegue completar a comunicação do token...

A proposta de adequação à RFC teria grandes impactos na API de vocês, mas pequenos ajustes poderiam ser feitos (como por exemplo aceitar 204 na resposta).

Seja como for, é legal saber que o pedido será analisado. Ficaria mais simples de fazer integrações se tudo fosse no padrão internacional do HTTP 1.1, mas como eu mencionei as mudanças seriam significativas.

[guilhermecotaGn]

Muito bem pontuado, @davi5e.

Sem dúvidas, a adequação à RFC faz com que a API siga em conformidade com a semântica de solicitação e resposta dos métodos HTTP/1.1, padrão que já temos aplicado na API Pix, conforme mencionou.

Referente à API de cobranças (boletos, carnê, cartões), já estamos com o projeto de refatoração da API para esta melhoria, e tentaremos o mais breve possível liberar esta atualização para facilitar a integração, seguindo os padrões.

Pontuo que estamos sempre abertos para sugestões, melhorias e agradeço mais uma vez por sua contribuição!