search

gerencianet / gn-api-sdk-php

SDK em PHP integrada às APIs da Gerencianet preparada para emissão de cobranças Pix com QR Code e Pix Copia e Cola, split/divisão de Pix, boletos, carnês, cartão de crédito, assinatura, link de pagamento, marketplance, iniciação de pagamento Pix via Open Finance, pagamento de boletos, dentre outras funcionalidades.
https://dev.gerencianet.com.br/docs/instalacao-sdk-php
MIT License
85 stars 45 forks source link

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

Open davi5e opened 3 years ago

davi5e commented 3 years ago

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 commented 3 years ago

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

Desde já, obrigado!

guilhermecotaGn commented 3 years ago

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

davi5e commented 3 years ago

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 commented 3 years ago

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!