Wrong HTTP request building when variable contains array (or object)

[e-oz]

Please turn on console and run this plunker: http://plnkr.co/edit/xGqtovSsNOYFGm9XzLsr?p=info

then in Network tab look at request. It will be:
/api/resource?fields=ID&fields=Name
when should be
fields%5B0%5D=ID&fields%5B1%5D=Name

If we will try to replace array with an object, result will be even worse:
http://plnkr.co/edit/pdvvUk9HCVGSKPwz7S3m
/api/resource?fields=%7B%220%22:%22ID%22,%221%22:%22Name%22%7D
decoded it looks:
/api/resource?fields={"0":"ID","1":"Name"}

If there is any workaround for this issue, please let me know.

[pkozlowski-opensource]

So, this is kind of the same as #7363 (and others). The trouble is that there are many possible serialization schemas for request params, so we are probably going to abstract this in a service, so people can swap it at will to match their backend's requirements.

Closing as a duplicate of #7363, working on a service.

[e-oz]

I agree this is duplicate but I don't agree that there are many possible serialization schemes. In #7363 author expects same scheme in output and I'm sure it's only legit scheme.

[pkozlowski-opensource]

@Jamm hmm, afaik there are multiple "valid" serialization schemas for arrays. Let's take as an example the following literal defining request params:

{ countries: ['US', 'GB']}

The 3 different possible serialization schemas I'm aware of are:

• ?countries=US&countries=GB (often used in Java)
• ?countries[]=US&countries[]=GB (afaik often used in PHP / Rails)
• effect of calling JSON.toString() on { countries: ['US', 'GB']}

It is hard to elect one schema as "the right one" so this is why I'm proposing to abstract it behind a dedicated service.

Anyway, let's move the discussion to #7363