Implementando APIs TCGI

Este documento tem por objetivo demonstrar o padrão e as dificuldades que poderão ser encontradas durante a implementação de APIs para consumo de frontends interno e externo.

Documentação para padronização: 3. Elaborando uma Mensagem Padronizada - REST/JSON

Classe Controller

- Classe controller onde conterá as rotas e verbos para consumo da API deverá ser criada no projeto RM.IMB.API na pasta Common obrigatoriamente
   a LIB monta o swagger baseada nas informações da dll com final API.
- A classe de controller deverá receber minimamente os atributos 
  [RoutePrefix("imb/v1/comissao")] //rota padrão de todos os serviços disponibilizados pelo TCGI 
  [RMSController("ImbComissaoRegraServer")]  
  [AllowAnonymous]
  [RMSLicense(IgnoreLicense = true)] //Licenças diferenciadas PDC, PI, APP
- Método que fazem parte das rotas na classe de controller devem estár como publico e receberem minimanente os atributos
  (Método de exempo da classe controler: public ImbComissaoRegraEntity GetReadRecord(int idcorretor){ regras do metodo } )
[HttpGet] 
[Route]
 - Atributo utilizado para determinar se deverá citar no caminho da API o nome ou não, se deverá passar valores na assinatura diretamente ou no caminho.

        Exemplo: [Route] - não informando nenhum caminho ou parametro - deve seguir o método acima - http://localhost:8055/api/imb/v1/comissao?idcorretor=1
                        [Route("corretores")] - está informando que a rota deverá conter o caminho "corretores" - http://localhost:8055/api/imb/v1/comissao/corretores
                        [Route("corretor/{idcorretor}")] - deverá informar o caminho e a chave diretamente.  - http://localhost:8055/api/imb/v1/comissao/corretor?idcorretor=1
                        [Route("corretor/{idcorretor}")] - deverá informar o caminho e a chave diretamente. - http://localhost:8055/api/imb/v1/comissao/corretor/1
  
- Deverá ser criada a classe model que será utilizada no controler, está é o modelo utilizado para setar os valores e fazer transformação em Json.
  Nesta classe as variaveis declaradas para recebimento dos valores deverão conter os atributos para transformação da classe modelo de objeto para um tipo Json.
  [JsonProperty("IDCOMISSAO")]

Importante: Deletar o _Broker.dat para ser regerado após criar todas as classes envolvidas no processo de disponibilização da API.

Swagger

Para saber se seu controller ou mesmo a rota foi publicada corretamente no serviço do host da aplicação você poderá acessar o caminho http://{dominio}:{ApiPort}/api/swagger/, a lista das apis e rotas demoram para serem carregadas
(Dica: para carregar mais rápido, antes de chamar o swagger, vá até a pasta BIN da aplicação e apague todas as dlls "RM.*.API.dll" com exceção da dll RM.IMB.API.dll, assim o carregamento será mais rápido).
Após serem carregadas, pesquise pelo nome do seu controller e depois pela rota. Para saber mais sobre swagger Totvs clique aqui.

    Importante: O Host da maquina que está sendo verificado o serviço, deverá estar rodando com autorização de administrador, atenção com o firewall.

Video demonstração de verificação da API:

Swagger UI - Verificando API controller está disponível.mp4

Testando o consumo dos serviços da API

1 - POSTMAN
    - Você pode utilizar autenticação "Basic Auth" para este formato deverá informar 'Username' e 'Password' campos que abriram logo abaixo na tela após selecionar a opção informada.
    - Recomendamos utilizar a autenticação 'Bearer', caso a opção não apareça no seu postman, poderá digitar manualmente na aba 'Headers' na opção 'Key' o descritivo "Authorization" e em 'value' "Bearer TOKEN ENCONTRADO APÓS CONSUMO DO SERVIÇO DE FORNECIMENTO DO TOKEN", para geração do token utilize a API http://localhost:8055/api/connect/token, quando for utilizar o serviço para geração do token, deverá utilizar a autenicação basica, Para saber sobre Token Totvs RM.

Postman - Consumindo a API após estar visivel no Swagger.mp4