The problem with Go’s default HTTP handlers

Re:The problem with Go’s default HTTP handlers by dralley on Tuesday August 09, 2022 @12:02PM (#32399744)

I like the way Axum for Rust handles this. All response handlers return something that implements IntoResponse. Lots of types implement IntoResponse, thus making the simple cases really streamlined.

async fn create_user( Json(payload): Json<CreateUser>, ) -> impl IntoResponse {

    let user = User {
        id: 1337,
        username: payload.username,
    };

    // this will be converted into a JSON response
    // with a status code of `201 Created`
    (StatusCode::CREATED, Json(user))

}

If the handler is complex enough that branches can't all return the same type, you can just add .into_response() to each return site, and now you're just returning a response, which also implements IntoResponse (as a no-op).

This avoids the problem discussed in this article while also avoiding much of the boilerplate of manually building responses.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by masklinn on Tuesday August 09, 2022 @12:12PM (#32399893)

I’ve not yet gotten to use it, but I understand Axum also implements IntoResponse for Result<A: IntoResponse, B: IntoResponse>, which is very convenient for the sort of error code of the above.

It’s one of my biggest annoyance with Warp: it only implements Reply for `Result<T, http::error::Error>`, so if you have a faillible handler with more complicated error types (e.g. with a json body, or even a 200 response for RPC handlers) you’re in the awkward position of having to join the paths back (usually by converting everything to a Response by hand), which makes mistakes easier.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by zaarn on Wednesday August 10, 2022 @07:00AM (#32410070)

Correct, I spent about half an hour implementing IntoResponse for my own project's error type, but now I can just use normal error handling and I get presented with an error page on any issues. It's quite magic (not really, very streamlined).

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by laumars on Tuesday August 09, 2022 @03:46PM (#32403211)

There are Go HTTP libraries that behave that way too. This article only refers to the one in standard library.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by scriptsmith on Tuesday August 09, 2022 @09:55PM (#32407068)

Thank you! I ran into this branching problem the other day, ended up trying to return a complicated boxed future and gave up.

In retrospect it makes sense to do it the way you mentioned. I think because I’m not as confident with traits and rust’s brand of async I tried to get it to work the same way I would in other languages, which is to mess with the function’s return type myself, rather than let the compiler figure it out.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by Winsaucerer on Tuesday August 09, 2022 @11:23PM (#32407552)

Yep, it's a good tip, something I'd been hitting too!

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by pram on Tuesday August 09, 2022 @12:45PM (#32400349)

That is what Gin does.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by unscaled on Wednesday August 10, 2022 @12:17AM (#32407812)

No, that's exactly the opposite of what it does. The article above explicitly criticizes gin for not returning a value.

Echo is closer to the pattern described above, but:

1. Echo lets you return an error response, but doesn't let you customize how the error is rendered _in a modular way_. You can only have a single global custom error handler that decides how to serialize the errors, and it needs to have knowledge of how to properly serialize every kind of error in your app. I have to admit this is generally good enough for most of the apps, and I don't think you can do any better in Go, considering it doesn't have type classes like Rust. The best that you can do is to let errors implement a CustomHttpRenderer interface on their own and try to cast into it — but this is already doable with a custom error renderer in Echo.

2. Echo doesn't let you return a non-error Response from the handler - instead it's written directly to the ReponseWriter. This approach makes writing unit tests several orders of magnitude harder and also means you can forget to write a successful response in some cases. You can also both write a response directly and return an error, which cannot result in a valid behavior (Echo will take the safe route and just ignore the error code and do nothing).

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by pram on Wednesday August 10, 2022 @09:52AM (#32411952)

Axum isn't returning anything, IntoResponse outputs to HTTP. The error type in a handler is Infallible.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by maccard on Tuesday August 09, 2022 @06:24PM (#32405305)

Gin is excellent. It's the right balance of batteries included, sensible defaults, and black magic

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by suremarc on Tuesday August 09, 2022 @06:48PM (#32405578)

You don't return anything in Gin.

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by merb on Tuesday August 09, 2022 @02:59PM (#32402385)

the problem is that when you use NO_CONTENT that you prolly can violate the http spec. (you can do that with both)

[ Parent | on HN ]

Re:The problem with Go’s default HTTP handlers by zaarn on Wednesday August 10, 2022 @07:02AM (#32410076)

A lot of HTTP frameworks let you violate the HTTP spec to a surprising degree. Though with Rust you can just double check the return data with a middleware for Axum.

[ Parent | on HN ]