Essa é uma entidade abstrata que representa uma resposta para as solicitações feitas a API. A ideia é seguir algumas das especificações do JSON:API 1.0 acerca da estrutura de JSONs que serão consumidos por diferentes APIs.

A estrutura básica do JSON é a seguinte:

• No top level devem existir ao menos um dos elementos data, meta e error. Especificamente, se existe o elemento error não deve existir o elemento data. Para permitir esse comportamento, a classe AbstractResponse permite que subclasses sobrescrevam métodos que tratam a adição de erros e/ou meta-dados.
• O elemento data pode ser um único recurso ou uma coleção de recursos. Independente do caso, todo recurso deve possuir ao menos um id e um type. Abaixo um exemplo seguindo as especificações onde a API retornou um recurso utilizado pela home para exibir dados da educação brasileira a nível nacional.

{
  "data": {
    "type": "eduData",
    "id": 1,
    "attributes": {
      "ied": {
        "meanCategory": "Docente que tem entre 25 e 300 alunos e atua em um ou dois turnos em uma única escola e etapa.",
        "mean": 2.88
      },
      "ird": {
        "meanCategory": "Média-baixa",
        "mean": 2.9615
      },
      "tdi": {
        "mean": 16.2
      },
      "icg": {
        "meanCategory": null,
        "mean": null
      },
      "afd": {
        "meanCategory": "Docentes com licenciatura em área diferente daquela que leciona, ou com bacharelado nas disciplinas da base curricular comum e complementação pedagógica concluída em área diferente daquela que leciona.",
        "mean": 2.062
      },
      "country": "Brasil"
    }
  }
}

A classe AbstractResponse facilita a geração das respostas nesse formato e permite que subclasses escolham especificamente o tipo de resposta através do uso de generics.

Essa é um exemplo de Pull Request (PR) com solicitação de revisão e comentários.

Nesse branch, foi implementada a entidade AFD utilizando as anotações do JPA (Java Persistence API). Para utilizada o JPA, foi adicionada uma nova dependência no pom.xml (spring-boot-starter-data-jpa)

Adição das automações usando Github Actions. Por conta das mudanças realizadas no pom.xml, só vamos conseguir rodar a aplicação se for possível a conexão com o banco de dados (no application-dev.properties existe a configuração padrão do url e do usuário que deve ser utilizado pelo Spring).

Realizei vários testes em outro fork e funcionou como esperado. Quando integrarmos esses códigos, para cada PR que abrirmos serão executados os testes unitários (ainda precisam ser produzidos). Ao realizar o merge na main, passando um número de versão no commit de merge, uma imagem Docker da aplicação é criada e um release aqui no Github também é gerado.

Podemos liberar a primeira versão pro front já ter como testar e possivelmente encontrar alguns erros também. Atualmente, já temos o controlador dos dados nacionais pronto (faltando apenas os dados do Ideb, que serão utilizados quando tivermos o BD pronto).

Já foram adicionas as correções do CORS (#35) e outras correções menores. O controlador já consegue lidar com dados faltantes (colocamos os valores para null).

O quê vocês acham? @Arthursca @mrjohnnus @LuizMFL @lucas-lins

Organizei (sem implementações complexas) as classes necessárias para o funcionamento do sistema (seguindo o documento de análise e projeto).

src
└───main
    └─java
    |  └─edu/apigestor
    |    └─control
    |      └─controllers
    |      └─services
    |           └─imp
    |      └─mappers
    |    └─data
    |      └─repositories
    |    └─entity
    |      └─domain
    |      └─response
    |
    └─resources

Segunda versão com novas funcionalidades. Todas funcionalidades da home estão implementadas:

• Indicadores educacionais a nível nacional;
• Indicadores educacionais a nível regional;
• Lista de escolas com nome similar;

Adiciona um método utilitário para checar se existe Ideb para um dado ano. Podemos checar antes de fazer chamadas ao BD se existe Ideb para aquele ano, facilitando a construção das respostas :)

Adiciona construtores às classes de domínio e aplica o estilo Java do Google (indentação, ordenamento, etc). Não foram realizadas mudanças estruturais nas classes.

Salvando esse PR como rascunho para discutirmos com calma depois. Aqui tem uma pequena implementação do controlador para os dados da home (dados gerais sobre educação brasileira e lista de escolas dado um nome de escola).

Se já tiverem tudo configurado localmente, é possível acessar http://localhost:8080/home/country/brazil, onde é retornado o seguinte JSON:

{
  "data": {
    "type": "eduData",
    "id": 2,
    "attributes": {
      "ied": {
        "meanCategory": "Docente que tem entre 25 e 300 alunos e atua em um ou dois turnos em uma única escola e etapa.",
        "mean": 2.88
      },
      "ird": {
        "meanCategory": "Média-baixa",
        "mean": 2.9615
      },
      "tdi": {
        "mean": 16.2
      },
      "icg": {
        "meanCategory": null,
        "mean": null
      },
      "afd": {
        "meanCategory": "Docentes com licenciatura em área diferente daquela que leciona, ou com bacharelado nas disciplinas da base curricular comum e complementação pedagógica concluída em área diferente daquela que leciona.",
        "mean": 2.062
      },
      "country": "Brasil"
    }
  }
}

Caso seja solicitado dados de um outro país (e.g., http://localhost:8080/home/country/japan) é retornado um JSON informando um erro (o código HTTP da resposta é 400, indicando um BAD REQUEST por parte dos clientes):

{
  "error": {
    "id": "3",
    "status": "400",
    "title": "Country 'japan' not found"
  }
}