Improving the code from the official Go RESTful API tutorial(benhoyt.com)

Improving the code from the official Go RESTful API tutorial

https://benhoyt.com/writings/web-service-stdlib/

3 comments

An aside:

    // album represents data about a record album.
    type album struct {
        ID     string  `json:"id"`
        Title  string  `json:"title"`
        Artist string  `json:"artist"`
        Price  float64 `json:"price"`
    }

I've always wondered why there's no capacity to tag the entire struct in Golang, for situations like this. Either

    `json:expose-private-members`    
    type album struct { id string ... }

    `json:lowercase-public-members`
    type album struct { ID string ... }

To avoid having to repeat yourself twice and cut down on the noise, considering that these tags are picked up via reflection anyway, why not tag the type itself? If you wanted, you could always have field tags override struct tags if necessary.

benhoyt5 lat temu

I suspect it's because Go's general philosophy is that it's better to be verbose and explicit (than terse and magical). Probably falls under "clear is better than clever" from Rob Pike's Go Proverbs: http://go-proverbs.github.io/

I think if this feature was added, it would not be with struct tags, but with an Encoder.SetFieldTransform(json.SnakeCase) or similar setting.

That might be quite a nice feature, actually. You could provide your own function to transform names when marshaling, and for unmarshaling it would strip punctuation and match case insensitively (because it's hard to do the reverse transform, for example should user_id go to UserId or UserID, and if the latter, how does the transform know?).

In any case, it seems like an issue was opened proposing something like that a couple of years ago (https://github.com/golang/go/issues/23027), and Russ Cox responded that the JSON package is basically done, but you could either fork it and add the feature, or use a tool that modifies struct tags like https://github.com/fatih/gomodifytags

theandrew1685 lat temu

Pretty interesting... I really feel like I'm on Ben's side of this. Using higher-level libraries to simplify ideas and claiming that real bugs are out of scope are both things that might sound good on paper but are likely to cause harm in the long term.

I'd rather be overtly honest about the nuance and potential pitfalls that come along with building even a super simple app. HTTP timeouts are important, concurrency needs to be safe, user input must be validated, etc etc. I don't think it does anyone a favor (especially new devs) to hide these details. Put them out there with well-written descriptions and explanations.

tomcam5 lat temu

This code feels more like official Go than the official Go article on which it is based. It achieves its stated goals and feels like the perfect place to start a typical web app. Very helpful