Skip to content

Latest commit

 

History

5 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

InvestTrack API

API REST para gerenciamento de ativos financeiros, desenvolvida com Java e Spring Boot como projeto de estudo e evolução em desenvolvimento back-end.

O projeto aplica conceitos de arquitetura em camadas, persistência de dados, validação, tratamento de exceções e desenvolvimento de APIs REST.


Sobre o projeto

O InvestTrack API é uma aplicação back-end desenvolvida para realizar o gerenciamento de ativos financeiros.

Atualmente, a API permite cadastrar, consultar, atualizar e excluir ativos, além de realizar buscas específicas por ID e ticker.

Os dados são persistidos em banco de dados utilizando Spring Data JPA e Hibernate, e a aplicação possui validações de entrada, controle de ticker duplicado e tratamento global de erros.

O projeto está sendo desenvolvido de forma progressiva, com o objetivo de aplicar na prática conceitos utilizados no desenvolvimento profissional de aplicações back-end com Java e Spring Boot.


Tecnologias utilizadas

My Skills


Conceitos praticados

Durante o desenvolvimento do projeto, estão sendo aplicados conceitos como:

  • Programação Orientada a Objetos
  • APIs REST
  • Arquitetura em camadas
  • Separação de responsabilidades
  • Injeção de dependências
  • Controller
  • Service
  • Repository
  • Persistência de dados
  • JPA
  • Hibernate
  • Entidades
  • Spring Data JPA
  • Consultas derivadas
  • Optional
  • ResponseEntity
  • Status HTTP
  • Bean Validation
  • Validação de dados
  • Exceptions personalizadas
  • Tratamento global de exceções
  • Padronização de respostas de erro
  • Maven
  • Organização de pacotes
  • Git e GitHub

Arquitetura

A aplicação utiliza uma arquitetura em camadas:

Cliente
   ↓
Controller
   ↓
Service
   ↓
Repository
   ↓
Banco de Dados

Controller

Responsável por receber as requisições HTTP, encaminhar os dados para a camada de serviço e devolver as respostas da API.

Service

Responsável pelas regras de negócio da aplicação.

Repository

Responsável pela comunicação com o banco de dados utilizando Spring Data JPA.

Model

Responsável por representar as entidades utilizadas pela aplicação.

Exception

Responsável pelas exceptions personalizadas e pelo tratamento global dos erros da API.


📁 Estrutura do projeto

src/
├── main/
│   └── java/
│       └── com/example/investtrack_api/
│           │
│           ├── InvesttrackApiApplication.java
│           │
│           ├── controller/
│           │   └── AssetController.java
│           │
│           ├── service/
│           │   └── AssetService.java
│           │
│           ├── repository/
│           │   └── AssetRepository.java
│           │
│           ├── model/
│           │   └── Asset.java
│           │
│           └── exception/
│               ├── DuplicateTickerException.java
│               ├── ErrorAPI.java
│               └── GlobalExceptionHandler.java
│
└── test/
    └── java/
        └── com/example/investtrack_api/
            └── InvesttrackApiApplicationTests.java

Funcionalidades

Atualmente, a API possui as seguintes funcionalidades:

  • Cadastro de ativos financeiros
  • Listagem de todos os ativos cadastrados
  • Busca de ativo por ID
  • Busca de ativo por ticker
  • Atualização de ativos
  • Exclusão de ativos
  • Geração automática de ID pelo banco de dados
  • Persistência dos dados
  • Bloqueio de ticker duplicado
  • Comparação de ticker ignorando letras maiúsculas e minúsculas
  • Validação dos dados recebidos pela API
  • Validação de campos obrigatórios
  • Validação de preço
  • Tratamento global de exceções
  • Padronização das respostas de erro

Endpoints

Método Endpoint Descrição
GET /assets Lista todos os ativos
GET /assets/{id} Busca um ativo pelo ID
GET /assets/ticker/{ticker} Busca um ativo pelo ticker
POST /assets Cadastra um novo ativo
PUT /assets/{id} Atualiza um ativo existente
DELETE /assets/{id} Exclui um ativo

📋 Listar todos os ativos

GET /assets

Retorna todos os ativos cadastrados no banco de dados.

Exemplo de resposta:

[
  {
    "id": 1,
    "name": "Bitcoin",
    "ticker": "BTC",
    "type": "CRYPTO",
    "currentPrice": 330000
  },
  {
    "id": 2,
    "name": "Ethereum",
    "ticker": "ETH",
    "type": "CRYPTO",
    "currentPrice": 18000
  }
]

Status esperado

200 OK

🔎 Buscar ativo por ID

GET /assets/{id}

Exemplo:

GET /assets/1

Exemplo de resposta:

{
  "id": 1,
  "name": "Bitcoin",
  "ticker": "BTC",
  "type": "CRYPTO",
  "currentPrice": 330000
}

Caso o ativo não exista:

404 Not Found

Buscar ativo por ticker

GET /assets/ticker/{ticker}

Exemplo:

GET /assets/ticker/BTC

A busca não diferencia letras maiúsculas e minúsculas.

Portanto:

BTC
btc
Btc

são tratados como o mesmo ticker.

Caso o ativo seja encontrado:

200 OK

Caso nenhum ativo seja encontrado:

404 Not Found

Cadastrar ativo

POST /assets

Exemplo de requisição:

{
  "name": "Bitcoin",
  "ticker": "BTC",
  "type": "CRYPTO",
  "currentPrice": 330000
}

Exemplo de resposta:

{
  "id": 1,
  "name": "Bitcoin",
  "ticker": "BTC",
  "type": "CRYPTO",
  "currentPrice": 330000
}

Status esperado

201 Created

O ID é gerado automaticamente pelo banco de dados.

Mesmo que um ID seja enviado manualmente durante o cadastro, a aplicação permite que o banco seja responsável pela geração do identificador.

Caso o ticker já esteja cadastrado:

409 Conflict

Caso existam campos inválidos:

400 Bad Request

Atualizar ativo

PUT /assets/{id}

Exemplo:

PUT /assets/1

Exemplo de requisição:

{
  "name": "Bitcoin",
  "ticker": "BTC",
  "type": "CRYPTO",
  "currentPrice": 350000
}

Caso o ativo seja encontrado e atualizado:

200 OK

Caso o ativo não exista:

404 Not Found

Caso o ticker informado já pertença a outro ativo:

409 Conflict

Caso os dados enviados sejam inválidos:

400 Bad Request

O ativo pode manter seu próprio ticker durante uma atualização. O conflito ocorre somente quando o ticker informado já pertence a outro registro.


Excluir ativo

DELETE /assets/{id}

Exemplo:

DELETE /assets/1

Caso o ativo seja removido com sucesso:

204 No Content

Caso o ativo não exista:

404 Not Found

Validações

A API realiza validações nos dados recebidos antes de cadastrar ou atualizar um ativo.

Entre as regras atuais estão:

  • Nome obrigatório
  • Ticker obrigatório
  • Tipo obrigatório
  • Preço maior que zero
  • Ticker não pode estar cadastrado em outro ativo

As validações relacionadas aos campos são realizadas utilizando Bean Validation.

As regras que dependem de informações existentes no banco de dados, como a verificação de ticker duplicado, são tratadas na camada de Service.

O fluxo ocorre da seguinte maneira:

Requisição
    ↓
Controller
    ↓
Bean Validation
    ↓
Service
    ↓
Regras de negócio
    ↓
Repository
    ↓
Banco de Dados

Consultas com Spring Data JPA

O projeto utiliza consultas derivadas do Spring Data JPA, permitindo criar consultas através da nomenclatura dos métodos definidos no Repository.

Atualmente são utilizadas consultas para:

  • Verificar se um ticker já existe
  • Verificar se um ticker pertence a outro ativo
  • Buscar um ativo pelo ticker
  • Ignorar diferenças entre letras maiúsculas e minúsculas

Exemplos:

existsByTickerIgnoreCase(...)
existsByTickerIgnoreCaseAndIdNot(...)
findByTickerIgnoreCase(...)

O Spring Data interpreta os nomes dos métodos e cria as consultas necessárias para acessar o banco de dados.

Isso evita a necessidade de carregar todos os registros apenas para realizar verificações simples.


Tratamento de erros

A aplicação utiliza tratamento global de exceções através de:

@RestControllerAdvice

O GlobalExceptionHandler é responsável por interceptar erros da aplicação e transformá-los em respostas HTTP organizadas.

Além disso, foi criada a classe ErrorAPI, responsável por padronizar o formato dos erros retornados pela API.

A estrutura contém informações como:

  • Status HTTP
  • Nome do erro
  • Mensagem
  • Data e horário
  • Campos inválidos, quando necessário

Exemplo de erro de validação

Ao enviar vários campos inválidos, a API pode retornar uma resposta semelhante a:

{
  "status": 400,
  "error": "Bad Request",
  "message": "Existem campos inválidos.",
  "timestamp": "2026-08-07T16:30:00",
  "fieldErrors": {
    "name": "O nome do ativo é obrigatório.",
    "ticker": "O ticker do ativo é obrigatório.",
    "currentPrice": "O preço deve ser maior que zero."
  }
}

O fieldErrors relaciona cada campo inválido à sua respectiva mensagem.


Exemplo de ticker duplicado

Caso seja feita uma tentativa de cadastrar um ticker que já existe:

{
  "status": 409,
  "error": "Conflict",
  "message": "O ticker informado já está cadastrado.",
  "timestamp": "2026-08-07T16:30:00",
  "fieldErrors": null
}

Status HTTP:

409 Conflict

Status HTTP utilizados

Status Significado
200 OK Operação realizada com sucesso
201 Created Ativo criado com sucesso
204 No Content Ativo excluído com sucesso
400 Bad Request Dados enviados são inválidos
404 Not Found Ativo não encontrado
409 Conflict Ticker já cadastrado

Banco de dados

Atualmente, o projeto utiliza o H2 Database.

A persistência dos ativos é realizada através de:

  • Spring Data JPA
  • Hibernate
  • JPA Repository

A entidade Asset é mapeada para o banco através do JPA e seus identificadores são gerados automaticamente.

O H2 é utilizado durante a fase atual de desenvolvimento por permitir uma configuração simples e rápida para testes e estudos.


Modelo de ativo

Atualmente, um ativo possui os seguintes dados:

Campo Tipo Descrição
id Long Identificador gerado pelo banco
name String Nome do ativo
ticker String Código de negociação
type String Tipo do ativo
currentPrice double Preço atual do ativo

Exemplo:

{
  "id": 1,
  "name": "Bitcoin",
  "ticker": "BTC",
  "type": "CRYPTO",
  "currentPrice": 330000
}

Fluxo de uma requisição

Um cadastro segue aproximadamente este fluxo:

POST /assets
      ↓
AssetController
      ↓
Bean Validation
      ↓
AssetService
      ↓
Verificação de ticker duplicado
      ↓
AssetRepository
      ↓
Spring Data JPA
      ↓
Hibernate
      ↓
H2 Database

Esse fluxo mantém responsabilidades diferentes separadas entre as camadas da aplicação.


Testes da API

Durante o desenvolvimento, os endpoints podem ser testados utilizando o Postman.

Entre os cenários testados estão:

  • Cadastro válido
  • Cadastro com dados inválidos
  • Cadastro de ticker duplicado
  • Listagem de ativos
  • Busca por ID
  • Busca por ticker
  • Busca de ativo inexistente
  • Atualização de ativo
  • Atualização mantendo o próprio ticker
  • Tentativa de utilizar ticker de outro ativo
  • Exclusão de ativo
  • Exclusão de ativo inexistente

Testes automatizados mais completos fazem parte das próximas etapas de evolução do projeto.


Como executar

1. Clone o repositório

git clone https://github.com/PedroseleT/investtrack-java-base

2. Entre na pasta do projeto

cd investtrack-api

3. Abra o projeto

Abra o projeto em uma IDE Java, como:

  • IntelliJ IDEA
  • Eclipse
  • VS Code com extensões para Java

4. Aguarde o Maven

Aguarde o Maven baixar e configurar as dependências do projeto.

5. Execute a aplicação

Execute:

InvesttrackApiApplication.java

6. Acesse a API

Por padrão, a aplicação será iniciada em:

http://localhost:8080

Os endpoints poderão ser testados utilizando ferramentas como Postman.


Exemplo de fluxo de utilização

Um fluxo possível de utilização da API é:

  1. Cadastrar um ativo
  2. Consultar todos os ativos
  3. Buscar o ativo pelo ID
  4. Buscar o ativo pelo ticker
  5. Atualizar seus dados
  6. Tentar cadastrar um ticker duplicado e receber 409 Conflict
  7. Enviar dados inválidos e receber 400 Bad Request
  8. Excluir o ativo
  9. Tentar buscá-lo novamente e receber 404 Not Found

Objetivo do projeto

O objetivo do InvestTrack é evoluir progressivamente de uma API de gerenciamento de ativos financeiros para uma aplicação back-end mais completa voltada ao gerenciamento de investimentos.

Ao longo dessa evolução, o projeto busca colocar em prática conceitos importantes do ecossistema Java, como:

Java
   ↓
Spring Boot
   ↓
API REST
   ↓
Arquitetura em camadas
   ↓
JPA / Hibernate
   ↓
Banco de Dados
   ↓
Validações
   ↓
Tratamento de erros
   ↓
Testes
   ↓
Segurança

O projeto também funciona como parte do portfólio de estudos em desenvolvimento back-end com Java e Spring Boot.


👨‍💻 Autor

Projeto desenvolvido para estudo e prática de desenvolvimento back-end com Java e Spring Boot.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages