Solve : Standardize API Response Format

[linisha15]

closes #24
Description

This PR introduces a standardized JSON response schema across all Flask API endpoints to ensure consistent response structures.

Currently, some endpoints return raw data (e.g., return jsonify(data), 200), while others return structured objects such as:

{
"message": "...",
"status_code": "success"
}

This inconsistency makes frontend integration and future maintenance more difficult, as consumers of the API cannot rely on a predictable response format.

🚀 Proposed Solution

A helper utility function api_response() has been introduced to enforce a consistent response schema across endpoints.

Standard Success Response
{
"success": true,
"message": "Optional human-readable message",
"data": { ... },
"error": null
}

Standard Error Response
{
"success": false,
"message": "Error description",
"data": null,
"error": "Detailed error info (optional)"
}

🛠 Implementation Details

Added a reusable helper function: api_response(success, message=None, data=None, error=None, status_code=200)

Refactored selected routes to use the new standardized response format

Preserved existing HTTP status codes (200, 400, 404, 500, etc.)

No endpoint URLs were changed

Example helper implementation:

from flask import jsonify

def api_response(success, message=None, data=None, error=None, status_code=200):
response = {
"success": success,
"message": message,
"data": data,
"error": error
}
return jsonify(response), status_code

[arnchlmcodes]

I noticed that PR #32 (global error handlers for #28) is being worked on in parallel and currently builds the error response structure manually. Since both changes appear to aim for the same standardized schema, it might be helpful to consider aligning that PR to use this helper as well, so the standardization is consistent end-to-end. Just suggesting this in case it helps keep everything unified

[linisha15]

@arnchlmcodes Thanks for pointing that out! I agree that aligning both PRs would help keep the schema consistent. I'm happy to coordinate or help refactor PR #32 to use this helper if that makes sense.

[Aaravanand00]

@linisha15 Great work on consolidating responses under api_response — this significantly improves consistency across routes

A few architectural suggestions that might make the standardization even stronger:

1. In some places we return success=False while keeping status_code=200. It might be more REST-consistent to align HTTP status codes with the success flag (e.g., 4xx for client errors, 5xx for server errors). That would make error handling more predictable for API consumers.

2. In several routes, the previous response dictionary (which already includes fields like "message" and "status_code") is passed entirely into data. This results in nested/duplicated metadata (top-level message + data.message). It could be cleaner to keep data strictly as the payload and avoid embedding transport-level metadata inside it.

3. Since PR feat:Global Error Handlers #28 #32 is introducing global error handlers, it might be worth ensuring that unhandled exceptions also route through api_response, so the response schema is unified end-to-end.

Overall, this is a strong step toward a predictable API contract — these tweaks would just make the design even more robust long-term.

[linisha15]

Hi @Aaravanand00 , thanks for the suggestions! I’ve updated the implementation:

Status Codes: Aligned HTTP codes (e.g., 201, 409) with the success flag and updated

api_response
to default to 400 on failure.
Clean Payloads: De-nested metadata from the data field, keeping it strictly for the response payload.
Global Error Handling: Integrated centralized handlers in

app.py
for 404, 500, and custom exceptions to ensure a unified schema end-to-end.
Everything has been verified with automated tests. Ready for review!