Implement GET /areas/{area_id}/data endpoint to read aggregated data from all components within a specific area

[mfaferek93]

Summary

Implement GET /areas/{area_id}/data endpoint to read aggregated data from all components within a specific area. This endpoint enables monitoring entire vehicle subsystems (powertrain, chassis, body) by collecting topic data from all components in the area and returning it in a single unified response.

The endpoint should:

• Aggregate data from all components in the specified area
• Include component identification in each data item for traceability
• Return structured response with area metadata and aggregated data
• Handle areas with no components gracefully
• Return 404 for nonexistent areas

---

Proposed solution (optional)

1. Add REST Handler (src/rest_server.cpp):

• Implement GET /areas/{area_id}/data handler
• Extract area_id from URL path
• Validate area exists in entity cache (return 404 if not found)
• Find all components in that area from entity cache
• For each component, call existing data_access_manager->get_component_data(namespace)
• Aggregate all topic data with component_id metadata
• Return combined response with area summary

2. Response Format:

  Success response (200):
  {
    "area_id": "powertrain",
    "component_count": 2,
    "data": [
      {
        "component_id": "temp_sensor",
        "component_namespace": "/powertrain/engine",
        "topic": "/powertrain/engine/temperature",
        "timestamp": 1732377600000000000,
        "data": {
          "temperature": 85.5,
          "variance": 0.0
        }
      },
      {
        "component_id": "rpm_sensor",
        "component_namespace": "/powertrain/engine",
        "topic": "/powertrain/engine/rpm",
        "timestamp": 1732377600100000000,
        "data": {
          "data": 2500.0
        }
      }
    ]
  }

  Error response (404):
  {
    "error": "Area not found",
    "area_id": "nonexistent"
  }

  Empty area response (200):
  {
    "area_id": "empty_area",
    "component_count": 0,
    "data": []
  }

3. Aggregation Logic:

• Query entity cache for all components where component.area == area_id
• For each component:
  • Call data_access_manager->get_component_data(component.fqn)
  • For each topic data returned, add:
    • component_id field (from component)
    • component_namespace field (from component)
  • Continue on component failures (log warning, don't fail entire request)
• Combine all results into single response array

4. Error Handling:

• Return 404 if area doesn't exist in cache
• Continue aggregation if individual component data fetch fails
• Log warnings for component-level failures
• Return partial results rather than failing entire request

---

Additional context (optional)

Performance Considerations

• Sequential component querying could be slow for areas with many components
• Consider documenting performance characteristics in README
• Future optimization: parallel component queries (defer to separate issue)

Demo Node Layout
Based on the demo nodes, the areas will return:

• powertrain: Engine temp sensor + RPM sensor (2 components)
• chassis: Brake pressure sensor + actuator (2 components)
• body: Door status sensor + light controller (2 components)

Example Use Cases

  Vehicle Subsystem Health Dashboard:
  # Get all powertrain metrics in one call
  curl http://localhost:8080/areas/powertrain/data

  # Response includes:
  # - Engine temperature from temp_sensor
  # - Engine RPM from rpm_sensor
  # - Each with component_id for identifying source
  # - Single API call replaces multiple component queries

  Multi-Component Monitoring:
  # Monitor entire chassis subsystem
  curl http://localhost:8080/areas/chassis/data

  # Returns:
  # - Brake pressure from pressure_sensor
  # - Brake command from actuator (if available)
  # - Useful for coordinated subsystem diagnostics

Data Traceability
Each data item must include:

• component_id - Which component produced this data
• component_namespace - Full namespace of the component
• topic - Full topic path
• timestamp - When data was sampled
• data - The actual topic payload

This allows API consumers to:

• Track data provenance (which component)
• Correlate data across components
• Build component-specific visualizations from aggregated response