Skip to content

Instantly share code, notes, and snippets.

@jmendiara jmendiara/
Last active Aug 29, 2015

What would you like to do?
Angular $http features wishlist

This is an opinionated list of desired Angular capabilities and feature lacks, to open debate and looking for best ways to solve them


  • We cannot be confident about the URL used as cache key: Removing, getting or updating $http cache entries in userland is hard and hacky. httpu.headers helps on solving this issue.
  • $cacheFactory.Cache is private: This causes reimplementing all the logic for a $cacheFactory API, instead of letting users to specify with kind of cache a $cacheFactory is returning.
  • We cannot control how a $cacheFactory.Cache key is generated: You have to decorate all your $cacheFactory implementations ($cacheFactory.Cache is private). Exposing a key generator method somewhere may help
  • We cannot know if a request comes from the server or the cache Core implementation in $http or an specific $http Caches decoration should be performed, maybe adding a userland header.


  • Every request traverses all the registered interceptors All interceptors needed for backend A, are traversed by requests against backend B (for example: A is your API backend, B is your webserver backend where you get templates from). When you are accessing several API backends, you have to code flags in every interceptors to guess if they apply. Specifying per-request o per-backend interceptors in core seems the best approach, as caches, paramSerializer (v2.4.0), transformRequest... httpu.composite helps on solving this issue.
  • Rejecting on request causes api inconsistency in subsequent responseError: cause of that undefined in the interceptor chain, rejecting in an interceptor request causes the first requestError reached to have the value of that rejection as param. But if a request fails in the core land (timeout or server error), the param to the first requestError is constructed by core in the resolvePromise. For example, it has a config property with the original request config. You have to code an object adaptation to keep consistency with interceptor.request rejections


  • We cannot control how a full URL is generated (serialized from params and finally constructed) Finally, the $httpParamSerializer landed in v2.4.0, allowing you to custom serialize the request params. But still there is not full control in core to construct URLs, for example, concatenating parameters with ; or make whatever crazy thing you want. httpu.urlbuilder helps on solving this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.