End-points

[eduardoworrel]

• Clonar o projeto e criar uma Branch [primeiro-nome][ultimo-nome]-feature-define-end-points

• Ao considerar particionar o PR em menores para facilitar a revisão crie PRs para a sua branch, por exemplo:
  eduardoworrel-feature-define-end-points << recebe pr de << eduardoworrel-feature-define-end-points-setup-empty-services

Criar os 3 end-points na aplicação e criar uma classe para intermedia a chamada a api do Azure e processar o retorno desta;

• localhost:9999/api/v1/validate?id={guid}&text={string}

  • **o campo text ** deve considerar o máximo de caracteres que o SqlServer pode armazenar
  • O campo guid não pode ser um Guid.Empty
  • *Considerando que algumas linguagens e o próprio SQL transformar true em 1 e false em 0, considero que a sutil diferença entre retornar 1 caracter (1 ou 0) ao invés de 4 ou 5(true ou false) podemos ter um pequeno ganho de performance que podemos validar se faz sentido.
    Sendo assim a api retorna int, 0 para invalido e 1 para valido

• localhost:9999/api/v1/rank

  • Não recebe parâmetros. nota: quando houver autenticação podemos pensar em uma estratégia de (Company/Organization) para que haja uma camada de autorização dos dados (eu não vejo os dados da companhia do vizinho a não ser que seja a chave-mestra, que pode gerar um dashboard anonimizado de todos os apps que usam aquele serviço)
  • retorna uma lista de incidentes

• localhost:9999/api/v1/rank?id={guid}

  • O campo guid não pode ser um Guid.Empty
  • retorna uma lista de incidentes

• Para os Services que os end-points chamarão podem ser 3 métodos sem implementação com throw new exceptions

• aplicar o comando dotnet csharpier . na raiz do projeto

• abrir um pull request da branch feature principal para a main e solicitar revisão do @eduardoworrel