Specifying multiple parameters for a string type silently coerces data about schema

[moraes]

This is not undefined behavior. You'll always get the first value from the raw query.

There should be a way to specify other behaviors, though.

[DanielHeath]

Ah - because parsing the url results in an ordered array, right.

Seems to me like the sort of thing that results in confused developers 6 months down the track if multiple params are involved:

eg given a querystring like ?api_query=get&api_key=af4eb2&filter=valid&order=desc&api_key=4bcfe13b
it's hard to spot that changing the api_key parameter at the end isn't going to change what the server sees.

[moraes]

Most request wrappers get the first value from the query/form when a single value is needed, but I saw some that get the last (werkzeug in Python if I'm not mistaken).

You need to be careful when building queries. Not hard to normalize the one from your example.

[DanielHeath]

In eg sinatra/rails you get a string if there's one and an array if there's multiple values, which lets you access each value.

If I'm writing an API that expects a parameter once and someone specifies it more than once, I'm going to assume they made a mistake.
I think it's better to return an error message in that situation rather than try to guess which one they meant, particularly if there isn't an agreed standard on how to make that decision.

[kisielk]

Maybe it would be possible to do something similar to the Header type in net/http: http://golang.org/pkg/net/http/#Header

The type itself is a map[string][]string, so it has all of the possible values available for the key if you want to get them directly from the map. The type's methods treat it as if it only has one value for each key.

[DanielHeath]

That's cool, I hadn't looked at that type before.

[DanielHeath]

But doesn't the URL package already expose url.Query() as type url.Values map[string][]string

[kisielk]

Right, nevermind that, I see what is happening now. I think different people will want different behaviours in this case so the only solution is to make it configurable, it doesn't seem like there's a good default, which I guess is the whole reason this issue even exists.

[moraes]

I think the current default is good. But I'd like that the API allowed you to override it, by implementing some kind of decoding interface.

An old idea I have is to implement something similar to the PropertyLoadSaver in App Engine's datastore, except that just for loading values (so PropertyLoader or something). This could also be a hook for validation (which is something I find particularly hard to do in Go because doing it manually is better than any helper API). Just for reference: https://developers.google.com/appengine/docs/go/datastore/reference#PropertyLoadSaver

It's not clear to me that this would fit, but the gist is that I want to make it more extendable somehow, keeping the convenience of sensible defaults like it is now.

[kisielk]

Right now we're loading the last value and I think it's going to stay that way.