[Bug] Go generated structs contain url annotations for every field

[arcurtis]

Describe the bug

The go model and SDK generators create structs for fern types. Each field in these structs contains a url annotation. These annotations are used for type safe URL param parsing in go. As far as I know, this is only useful server-side, so the SDK structs should not contain these annotations at all. These annotations are only useful in request types and so should not be in every model struct. Instead, they should be only in named request types.

To reproduce

Generate any fern type, e.g.,

types:
  User:
    properties:
      id: string
      name: string
      email: string

this results in the struct:

type User struct {
	Id    string `json:"id" url:"id"`
	Name  string `json:"name" url:"name"`
	Email string `json:"email" url:"email"`

	_rawJSON json.RawMessage
}

Expected behavior

I would expect the following struct

type User struct {
	Id    string `json:"id"`
	Name  string `json:"name"`
	Email string `json:"email"`

	_rawJSON json.RawMessage
}

The struct GetBar for the following API endpoint should have the url annotations, however

service:
  base-path: /foo
  endpoints:
    get:
      method: GET
      path: /bar
      request:
        name: GetBar
        query-parameters:
          baz:
            type: string

Version

Go generator 0.16.0

[amckinney]

As far as I know, this is only useful server-side, so the SDK structs should not contain these annotations at all.

This is actually the annotation that we use to serialize query parameters sent from the SDK. This approach is inspired by Google's go-querystring, but our approach includes a few minor differences and improvements for types specific to Fern.

These annotations are only useful in request types and so should not be in every model struct.

Now that we support deepObject query parameters (link), it's important that we include url tags in every object contained in the transitive closure from every request type. For example, using your example above, we actually support specifying the User as a query parameter.

Instead, they should be only in named request types.

This is actually something we debated when rolling out the feature to begin with. Including them everywhere upfront will actually enable us to someday roll out a new RequestOption that allows us to add arbitrary query parameters to individual endpoints (where the query parameter is not already defined on the API). We haven't needed this feature yet, but it's been discussed a bit here and there so I know it might be on the horizon.

With all that said, we made the decision to include them everywhere knowing that we could later change the behavior to include them in a stricter subset (like you're suggesting), but I'm still not convinced that we should do that in general (especially with that new upcoming feature in mind).