Renave-WS

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.

Público alvo deste manual

Este manual é destinado a desenvolvedores que criam e mantêm sistemas de software que consomem as funcionalidades do Renave-WS.

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.