O Renave-WS visa a registrar o movimento de compra e venda de veículos que sejam mantidos em estoque por estabelecimentos, conforme determinação do artigo 330 do Código de Trânsito Brasileiro.
Para um determinado veículo, o estado de estoque representa que esse veículo está em posse de um determinado estabelecimento, sendo que esse estabelecimento possui o propósito de comercializar esse veículo.
Neste manual encontram-se detalhada as regras de negócio das operações do Renave WS. Nesse contexto, o termo "estabelecimento solicitante" faz referência ao estabelecimento que está invocando a operação do WS.
O objetivo do Renave é registrar a movimentação de entrada e saída de estoque dos veículos dos estabelecimentos. Não compete ao Renave garantir a lisura do processo de compra e venda.
Contudo, para que o vendedor que vendeu seu veículo a um estabelecimento possa posteriormente alegar com assertividade sobre o fato, o Renave possibilita o upload da assinatura digital do ATPV. O vendedor tem ainda a possibilidade de registrar a comunicação de venda no cartório.
Mas como os itens descritos acima são opcionais, o Renave, que garante a autenticidade do estabelecimento com quem se comunica, presume a boa fé nas informações fornecidas pelo estabelecimento. A presunção de boa-fé nas relações com os usuários dos serviços públicos é uma diretriz traçada por decreto federal com vistas à desburocratização.
De qualquer forma, o processo se encerra com o atendimento físico no guichê do Detran de Jurisdição, que nesse momento constatará a assinatura física de ambos: comprador e vendedor.
Este manual é destinado a desenvolvedores que criam e mantêm sistemas de software que consomem as funcionalidades do Renave-WS.
Este manual é complementar ao Swagger do serviço.
Tipo do Campo | Formato |
---|---|
Data | Data no formato AAAA-MM-DDTHH:MM:SS. Exemplo: 2018-08-09T09:46:52 |
Boolean | true ou false |
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. |
É um json contendo os seguintes atributos:
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.