The current version of the $http
service has a hard-coded way of serializing request parameters. This one-and-only-one way of doing things causes practical problems to people using backends that have different serialziation schemas (mostly Rails and PHP).
More specifically, given this $http
call:
$http.get('http://google.com', {params: {foo: [1 ,2], bar: 'sth;else'}});
a URL produced by the default serialization schema will be:
http://google.com?foo=1&foo=2&bar=sth;else
This is unfortunatelly not the format expected by some (many?) people:
- PHP / Rails users would expect an array to be serialised to request params as:
foo[]=1&foo[]=2&bar=sth;else
- there is a question of special chars encoding - in this particular case
;
is expected to be percent-encoded by some backends
More generally, users might use backends that use a completly different serialisation schema, ex.:
http://google.com;foo=[1,2];bar=sth%3Belse
This per-backend variability of the URL serialization schema indicates that a URL building mechanism used by AngularJS should be configurable / overridable for users, instead of being fixed deep inside the framework.
As of today people are using $httpBackend
mock to test $http
-based code. The problem here is that while writing they functional code people operate on a different abstraction level as compared to tests (that are expressed in terms of backend interactions and not higher-level $http
interactions). One practical consequence of this approach is that people needs to re-construct a URL in their tests. In other words they need to duplicate logic burried deep-inside $http
.
Based on the above description we've got 2 main problems to solve:
- make URL-construction mechanism configurable to:
- make it easier for people to generate URLs in their tests - issues: #3311
The general idea is to extract the logic of the buildUrl to a separate service ($$httpUrl
? $urlBuilder
?) thus allowing:
- easy customisation of the serialisation schema (just swap the default service)
- community to build custom serialisation schemas dedicated to a given backend type
- usage of a new service from the unit tests to prepare string representation of a URL the same way as
$http
would do - easier unit-testing of the serialization service itself (both custom implementations from the community as well as built-in one)
After doing so we would introduce a new configuration param to the config object (paramsSerializer
? urlBuilder
?) that, by default, would invoke current logic from the extracted service. Adding a new config param would allow us to handle a use-case where users are hitting different backends with different serialization schemas.
- $http's serialization schema as of version 1.3.8
- jQuery's
param
method: http://api.jquery.com/jquery.param/
If you have different API end points customzing the serializer once doesn't really help you. Interceptors are also not very intuitive as you have to filter the requests you want to modify. I say, if we make this flexible, let's go all the way.
Do you mean it will make the code more compley or the API?