This repository contains a Java 21 + Spring Boot 3 application that consumes the official Cartola FC API and exposes:
- REST endpoints under the local Spring Boot app
- Swagger/OpenAPI documentation
- a static frontend served from
src/main/resources/static/
The application acts as an integration layer over https://api.cartola.globo.com, so reliability, null-safety, and predictable error handling matter more than clever abstractions.
src/main/java/com/api/cartolafc/config/: Spring configuration such asRestTemplatesrc/main/java/com/api/cartolafc/controllers/: REST controllers withResponseEntityand OpenAPI annotationssrc/main/java/com/api/cartolafc/services/: integration logic and business rulessrc/main/java/com/api/cartolafc/dtos/: JSON mapping recordssrc/main/java/com/api/cartolafc/utils/: shared helpers such asBASE_URL, rounding, slug normalization, and request headerssrc/main/resources/static/: static UI assetssrc/test/java/com/api/cartolafc/: unit testsdocs/explanation/: architecture and frontend notes
- Prefer small, localized changes that fit the existing package structure.
- Keep HTTP integration logic inside services. Do not duplicate external API calls in controllers.
- Prefer constructor injection, matching the current codebase style.
- Use Java
recordtypes for DTOs that model JSON payloads. - When mapping snake_case JSON fields, continue using
@JsonProperty. - Keep controller responses explicit with
ResponseEntityand preserve current status code behavior unless the change intentionally revises the contract. - Maintain or extend OpenAPI annotations when adding or changing public endpoints.
- Reuse
Utils.BASE_URLfor Cartola endpoints instead of hardcoding the base URL elsewhere. - Preserve the
User-Agentheader convention viaUtils.createHttpEntityWithUserAgent()when adding new outbound calls. - Treat external payloads as unstable: guard against
null, missing fields, invalid date strings, and unexpected fallback responses. - If an endpoint depends on round-specific data, validate that the returned round matches the requested round before using it.
- Keep shield URL cleanup behavior consistent when returning team data.
- Start locally:
./mvnw spring-boot:run - Run the full test suite:
./mvnw test - Run one test class:
./mvnw -Dtest=TeamsServiceTest test - Build the jar:
./mvnw clean package - Run with containers:
docker compose up --build
Useful local URLs after startup:
- App/UI:
http://localhost:8080/ - Swagger UI:
http://localhost:8080/swagger-ui/index.html - OpenAPI JSON:
http://localhost:8080/v3/api-docs - Healthcheck:
http://localhost:8080/actuator/health
- Prefer deterministic unit tests with Mockito over live calls to the Cartola API.
- Add or update tests whenever business logic changes, especially in services.
- For date-sensitive logic, avoid brittle assertions that depend on the current wall clock unless the code already follows that pattern and the test remains stable.
- When changing monthly score logic, cover at least:
- only finished rounds count
- only rounds in the current month count
- invalid or missing dates are ignored safely
- mismatched fallback rounds are ignored
- If JSON fixtures help readability, place them under
src/test/resources/fixtures/.
- The frontend is intentionally simple and static. Keep it lightweight.
- Prefer changing
src/main/resources/static/js/andsrc/main/resources/static/css/instead of introducing a new frontend toolchain. src/main/resources/static/data/times.csvis developer-local input and is gitignored. Do not rely on committing changes to it unless explicitly requested.- Keep the frontend compatible with the backend running on the same origin by default.
- If you change endpoint behavior, update
README.mdand relevant OpenAPI annotations. - If you change architecture or the static UI flow in a meaningful way, update the matching file in
docs/explanation/.
- Do not add new dependencies when the existing Spring Boot, JUnit 5, Mockito, and static asset stack is sufficient.
- Do not introduce secrets, tokens, or environment-specific URLs into the repository.
- Avoid network-dependent tests in CI-oriented code paths.
- Preserve backward compatibility for public endpoints unless the task clearly requires a breaking change.
- Read the relevant controller, service, DTO, and existing tests before editing behavior.
- After code changes, run the narrowest relevant test first, then the broader suite if the change crosses module boundaries.
- Prefer updating existing docs and tests alongside code in the same task.
- If a subdirectory develops specialized rules later, add a nested
AGENTS.mdclose to that code instead of overloading this root file.