API Documentation

Versioned and organized by features for scalability.

Base URL:

localhost:{port}/api/{feature}

---

Architecture Overview

Routes

Think of these as traffic signs.

• Define API endpoints
• Route HTTP requests to the appropriate controller

Controllers

Think of these as the receptionists.

• Receive and validate incoming requests
• Communicate with the appropriate service
• Send responses back to the client

Services

Think of these as the workers using the blueprints.

• Contain the core business logic
• Interact with models to fetch/update data
• Handle transactions via run_transaction utility
  • SQL statements are committed if successful, rolled back on failure
• Return Promises: resolve with result or reject with error

Models

Think of these as the blueprints of the data.

• Define the structure of the data
• Run direct SQL queries on the database
• Return Promises (important for SQLite3): resolve with result or reject with error

---

How They Work Together

1. Client sends a request to /api/{feature}
2. Router forwards the request to the appropriate Controller
3. Controller calls the corresponding Service for business logic
4. Service uses the Model to interact with the database

Data flows back:
Model → Service → Controller → Client

---

Features

Players

Required Fields

• _id – Unique UUID generated in the service
• username – Editable display name (not Steam username)
• steamid – Used to associate game data and HUD with correct player

Optional Fields

• firstName
• lastName
• avatar – Path to image in player_pictures/
• country
• team – Foreign key linking to teams._id
• extra – (Currently unused)

---

Teams

Required Fields

• _id – Unique UUID generated in the service
• name – Full team/organization name

Optional Fields

• country
• shortName – Abbreviated name (for long names)
• logo – Path to image in team_logos/
• extra – (Currently unused)

---

Matches

Required Fields

• _id – Unique UUID generated in the service

Optional Fields

(To be defined)