[compat] original httpbin returns either lists or scalars depending on input data

[splitbrain]

The answers between httpbin and httpbingo differ. httpbingo will always return an array for each parameter or header, while httpbin will return simple objects and use sub arrays only when needed. I think your behaviour is maybe a more sensible approach, but it's harder to read for humans and makes it hard to use httpbingo as a drop-in replacement for httpbin.

curl -s  'http://httpbin.org/get?foo=bar&foo=baz&what=this' |jq
{
  "args": {
    "foo": [
      "bar",
      "baz"
    ],
    "what": "this"
  },
...

$ curl -s  'http://httpbingo.org/get?foo=bar&foo=baz&what=this' |jq 
{
  "args": {
    "foo": [
      "bar",
      "baz"
    ],
    "what": [
      "this"
    ]
  },
...

[splitbrain]

I just noticed that this is somewhat a duplicate of #15 but not quite.

[mccutchen]

Yeah, I'm really torn on this. While making httpbingo.org a drop-in replacement for (at least the most common/basic functionality of) httpbin.org would be great, that particular pattern is particularly ugly to implement in Go. Maybe I'll take another pass at this and see how bad it really is.

[waitingsong]

I think common behaviour is:

GET  /get?foo=12&bar=23

Should got

{ 
 foo: "12",
 bar: "23",
}

and then

GET  /get?foo[]=12&foo[]=23

Should got

{ 
 foo: ["12", "23"],
}

[mccutchen]

and then

GET  /get?foo[]=12&foo[]=23

Should got

{ 
 foo: ["12", "23"],
}

Minor note: There is no special handling of ?foo[]=12&foo[]=23 style of query param in either go-httpbin or the original httpbin. That request will result in a response like

{
    "foo[]": ["12", "23"]
}

in both projects. Here's original httpbin:

$ curl -s 'https://httpbin.org/get?foo[]=1&foo[]=2' | jq .args
{
  "foo[]": [
    "1",
    "2"
  ]
}

and go-httbin:

$ curl -s 'https://httpbingo.org/get?foo[]=1&foo[]=2' | jq .args
{
  "foo[]": [
    "1",
    "2"
  ]
}

Note that the name of the argument is foo[], not foo.

[bbx-winner]

@mccutchen Hi, here's my solution to this issue: #73, wish for your comment.

[mccutchen]

I've taken a pass at this and #15 from time to time over the last couple of years, but I'm never satisfied with the complexity that it requires.

Ultimately, I don't think this (admittedly large) part of backwards-compatibility is worth pursuing, and prefer the consistency of our existing approach: any key-value pair where each key may correspond to one or more values will always be represented as a JSON array (AKA list, slice, etc) with one or more items.

I will gladly take a look at future pull requests if someone does come along with an implementation that somehow

• does not add too much complexity/duplication to the existing code base (unlike, e.g. support origin httpbin display style #73)
• is opt-in, so existing go-httpbin behavior is maintained by default