JSON response transform techniques

The way I'd go with is struct composition.

type UserID struct {
    UserID int
    Email string
}

type ModificationTimes struct {
    Created time.Time
    LastModified time.Time
}

type PostContent struct {
    Content string
    Attachments []Attachments
}

type Post struct {
    UserID
    ModificationTimes
    PostContent
}

In your example you mention one having email and ID and another having email and name. In my experience, somewhat to my surprise, I have found that typically in real life the things you want to separate like this do not overlap and you don't get problems with that sort of intersection. With the possible exception of an ID, which you can just then create more types that blend something with an ID if you need it. Types are cheap, don't be afraid to create many of them.

You may then notice that these things are actually their separate entities and you may start finding it useful to put methods on them, too.

Just watch the composition rules for marshaling method implementations; if you have

func (uid UserID) UnmarshalJSON([]byte) error {
    // code here
}

on the types as shown above, when trying to unmarshal a Post Go will find the UserID's UnmarshalJSON implementation and you may pull out your hair trying to figure out how to unmarshal the top-level with "normal" unmarshalling. The secret is something like

type MarshalPost Post

then you can unmarshal a *MarshalPost wrapped around a *Post and you'll get the "default" JSON unmarshaling behavior. That's a json.Unmarshal(b, (*MarshalPost)(&post)).

This article walks through various techniques for defining and omitting optional fields:

https://emretanriverdi.medium.com/json-serialization-in-go-a27aeeb968de

What you are seeking is called a "data transfer object" (DTO).

You can define separate DTOs for each endpoint and convert your database model instances to those DTOs. So your database models do not even care about JSON marshalling tags.

This method works particularly well for API backwards compatibility.

I haven’t done anything like this, but my first instinct would be to look into custom struct tags. I believe you can use them to implement custom de/serialization logic.

Another option might be implementing the un/marshal interface (I forgot what it’s called) for your struct. But I feel like this is probably not the way to go about it.

I've had a read of the various techniques and decided the best fit and the most secure as there's no possibility of leaking future information inadvertently is to have separate DTO response objects and use a NewXXX() function to write them from the DB models. It seemed a bit verbose initially but I'm still getting used to the more simple nature of Go and having written a few last night it actually works really well. Thanks for your comments and suggestions!