Swagger
Este manual é complementar ao Swagger do serviço.
Comportamento geral das operações
Tipos de retorno
| Tipo do Campo | Formato |
|---|---|
| Data | Data no formato AAAA-MM-DDTHH:MM:SS. Exemplo: 2018-08-09T09:46:52 |
| Boolean | true ou false |
HTTP Status Codes
| Status Code | Título | Descrição |
|---|---|---|
| 200 | OK | Tudo funcionou como esperado. |
| 201 | OK (criado) | Novo recurso criado como esperado. |
| 400 | Requisição inválida | A requisição não foi aceita pois o cliente enviou uma requisição inválida. |
| 401 | Não autorizado | Cliente não autenticado. |
| 403 | Proibido | Cliente autenticado não está autorizado a acessar o recurso. |
| 404 | Não encontrado | O recurso solicitado não existe. |
| 422 | Erro de negócio | O formato da requisição está correto, mas ocorreu algum erro de negócio. O detalhe do erro recebido pode ser repassado ao usuário final. |
| 500 | Erro no servidor | Ocorreu algum erro interno. |
Estrutura do response body em caso de erro (400, 404, 422, 500)
É um json contendo os seguintes atributos:
- titulo
- dataHora
- detalhe
- mensagemParaUsuarioFinal
- logIdRastreabilidade
Nem sempre todos esses atributos estarão presentes em todos os erros. Por exemplo, logIdRastreabilidade é exclusivo de erros 500 e mensagemParaUsuarioFinal é mais comum em erros 422.
Quando a aplicação cliente receber os erros 400 e 500, o recomendado é registrar todo o retorno em um log para que os desenvolvedores ou o suporte do serviço possam analisar o problema.
Sempre que mensagemParaUsuarioFinal for retornado, o conteúdo desse campo deve ser exibido ao usuário final. Idealmente o resto do retorno não deve ser exibido ao usuário final.
Ainda precisando de ajuda?