Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding axum::json! #2937

Closed
carllerche opened this issue Sep 24, 2024 · 2 comments · Fixed by #2962
Closed

Consider adding axum::json! #2937

carllerche opened this issue Sep 24, 2024 · 2 comments · Fixed by #2962
Assignees

Comments

@carllerche
Copy link
Member

Feature Request

Consider adding an axum::json! macro that matches the serde_json macro syntax and avoids the stutter:

async fn hello_world() -> impl IntoResponse {
    axum::json!({ "hello": "world" })
}

Motivation

Returning JSON is common. This would avoid adding an extra dependency in the end user's Cargo.toml and avoid some stutter (Json(json!(...))) without exposing the serde_json dependency.

@jplatte jplatte self-assigned this Sep 28, 2024
@SabrinaJewson
Copy link
Contributor

Given that this function returns impl IntoResponse anyway, might it be worth using an approach like typed-json to avoid the heap allocation?

@jplatte
Copy link
Member

jplatte commented Oct 6, 2024

That's exactly the sort of thing I was planning to write myself! Really nice that it already exists. I think that crate can be used directly by wrapping the generated type in axum::Json (and documenting that people are free to write either -> Json<impl Serialize> or -> impl IntoResponse). Would you be interested in making a PR for it?

edit: Actually maybe that crate also supports borrowing as part of the json!() expression? If yes, we can't wrap the result in Json (but we can use [something like] ErasedJson from axum-extra, which would either have to be moved into axum, or be part of the macro expansion).

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 a pull request may close this issue.

3 participants