Skip to content

Conversation

@suchithh
Copy link
Contributor

What

This PR adds proper response models for all endpoints to ensure the FastAPI documentation accurately represents the actual response structure. Fixes #118

Changes

  • Added HelloResponse model for root endpoint
  • Added TokenResponse model for auth endpoints
  • Added KeyStatistics model for /keys endpoint Add typing for OpenAPI response for /keys #149
  • Added PingResponse model for /ping endpoint
  • Added ValueCount model for /values endpoint
  • Updated route decorators with proper response_model parameters
  • Fixed endpoints that were returning plain strings instead of JSON objects

These changes improve the documentation accuracy in the OpenAPI spec and potentially type safety for the API.

@suchithh suchithh requested a review from a team as a code owner February 28, 2025 20:00

if cur.rowcount == 1:
return "ok"
return {"status": "ok"}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're changing the API here. @CharlesNepote is that ok?

Copy link
Contributor Author

@suchithh suchithh Mar 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're changing the API here. @CharlesNepote is that ok?

Regarding the change in the response model from a string ("ok") to a dict ({"status": "ok"}): while this change might affect the API, upgrading all responses to Pydantic models is key in the long run. One of FastAPI's core conventions is to use Pydantic models as much as possible, and changing the response structure now could potentially save many headaches in the future. Additionally, for validation failures (422), the response is already a JSON structure; depending on how the endpoint is used, it might be harder to check types on the frontend than to maintain consistency. Just my two cents.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@suchithh I understand your concern, but API change might have impact on reusers: we need to talk with them first and evaluate potential impacts.
So you should push a first PR without modifying the API, and a second one to push API changes.

@VaiTon
Copy link
Member

VaiTon commented Mar 1, 2025

Hey @suchithh , the /keys one was already tackled by #230.

@suchithh
Copy link
Contributor Author

suchithh commented Mar 1, 2025

Hey @suchithh , the /keys one was already tackled by #230.

Hi! I see two options here: I can either add a commit to remove that section, or I can redo the whole PR without it. Please let me know which one you prefer.

@VaiTon
Copy link
Member

VaiTon commented Mar 1, 2025

Hi! I see two options here: I can either add a commit to remove that section, or I can redo the whole PR without it. Please let me know which one you prefer.

@suchithh you can add a commit. We will squash commits before merging.

Copy link
Member

@CharlesNepote CharlesNepote left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @suchithh, we're almost done. Please distinguish your changes into two different PRs (see my comment below).


if cur.rowcount == 1:
return "ok"
return {"status": "ok"}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@suchithh I understand your concern, but API change might have impact on reusers: we need to talk with them first and evaluate potential impacts.
So you should push a first PR without modifying the API, and a second one to push API changes.

)
if cur.rowcount == 1:
return "ok"
return {"status": "ok"}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment.

""",
(product, owner, k.lower()),
)
if cur.rowcount == 1:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the next line are redundant with line 510-511.

@suchithh
Copy link
Contributor Author

suchithh commented Mar 4, 2025

Hi @CharlesNepote, thanks for the feedback. That makes sense and I figured I should've done that in the first place. I'll make the changes asap and make new PRs.

@suchithh
Copy link
Contributor Author

suchithh commented Mar 4, 2025

@CharlesNepote Hi Charles, please check my new PRs #238 #239

@alexgarel
Copy link
Member

Closing as we have now #238 and #239

@alexgarel alexgarel closed this Mar 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

"Hello" API: the server response is different from the one expected

4 participants