René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"RFC: Http interceptors and transformers","articleBody":"This issue is intended to define requirements for how the `Http` library should support common operations, like request and response transformations and error handling. The issue doesn't yet have a proposed design, but discussion, comments and suggestions are welcomed. Un-captured use cases are especially welcomed.\n# History\n\nTwo widely-used feature of angular1 are [request and response interceptors](https://docs.angularjs.org/api/ng/service/$http#interceptors) and [request/response transformers](https://docs.angularjs.org/api/ng/service/$http#interceptors). Interceptors and Transformers have different goals and constraints.\n- Interceptors are expected to have side effects, while transformers' exclusive purpose is to mutate requests or responses synchronously.\n- Interceptors may be asynchronous, tranformers must be synchronous\n- Interceptors are global and configured in Angular 1's \"compile\" phase, while transformers may be global or local. Global transformations can be mutated in the \"run\" phase.\n- Error interceptors are declared explicitly and separately from normal interceptors, whereas transforms handle normal and error cases.\n- Error interceptors can recover from errors by returning a resolved promise\n\nSome common use cases for interceptors:\n- Setting timeouts for requests\n- Setting custom XSRF tokens to request headers, as described in [$http docs](https://docs.angularjs.org/api/ng/service/$http#cross-site-request-forgery-xsrf-protection)\n- Add conditional parameters to all request urls (like an access token, or a/b-testing info)\n- Check authentication state before performing request, prompt user to authenticate\n- Have side effects on other parts of application (i.e. if response says user needs to authenticate, route them to login page)\n- Log all response errors returned from the server to a persisted log\n- Log total request/response time in order to do performance analysis\n- Filter out un-interesting request/responses from logs\n- Recover from request exceptions, or response errors (i.e. if request times out, return old data from cache)\n- Unwrapping responses (i.e. if response is {data: {foo:bar}}, return response.data)\n- Cache responses in a custom cache to be used by other services\n\nCommon use cases for transformers\n- serialize/de-serialize data, both directions\n- Strip headers (Angular 1 strips user-specified XSRF header with a default response transformation)\n\nWorth noting are some additional features provided by Angular 1 $http, which would otherwise be handled by transformers:\n- Url-based caching\n- Configurable parameter serialization\n- Header serialization\n# New Considerations for Angular 2’s Http Library\n\nAngular 2 and Angular 2 Http have some technical differences and philosophical differences from Angular 1.\n- Mutable global state is discouraged (i.e. `$http.defaults.transforms.push(...)`).\n- Angular 2 has no \"phases\" like \"config\" and \"run\".\n- Angular 2 provides hierarchical dependency injection, allowing users to modify bindings at different levels of an application's component tree.\n- Angular 2 Http is based primarily on `Observable` instead of Promise\n- Http has goals of supporting upload/download progress events, connection retrying, request cancellation, caching, and polling as first-class use cases.  \n## Current Options\n\nThe current library supports creating services that would provide shared interceptors and transformations. Here's an example of an Http-based service that would add custom headers, cache responses and log errors, based on the current RxJS implementation.\n\n``` js\nimport {Http, Request, IRequestOptions} from 'angular2/http';\nimport {ResponseCache} from './my-response-cache';\nimport {ErrorLog} from './my-error-log';\nclass MyConfiguredHttp {\n    constructor(public http:Http, public responseCache:ResponseCache, public errorLog:ErrorLog) {}\n    request(options:IRequestOptions) {\n        if (options.url in this.responseCache){\n            //Naive example (This Observable create syntax not yet supported)\n            //There's a cached response for this url, return it instead of performing request\n            return Rx.Observable.from([this.responseCache[options.url]]);\n        }\n\n        var req = new Request(options);\n        // Set a custom auth header\n        req.headers.set('sessionid', '123');\n        return this.http.request(req)\n            //Try performing the request up to three times\n            .retry(3)\n            .do(res =\u003e {\n                //Naive example, cache the response by the original url\n                this.responseCache[options.url] = res;\n            })\n            .doOnError(res =\u003e {\n                // Log the error with my app's logging service\n                this.errorLog.push(options, res);\n            });\n    }   \n}\n```\n\nQuestions to answer with final design:\n- What use cases are not able to be supported by the \"shared service\" approach?\n- How can the API be improved to make performance, robustness, and security the default path?\n- How is composability impacted by this approach, and how can it be improved?\n- How could this be simple and intuitive?\n- Does this require too deep of knowledge of Observables/Rx? \n- Does anyone actually read this far down on Github issues?\n","author":{"url":"https://github.com/jeffbcross","@type":"Person","name":"jeffbcross"},"datePublished":"2015-06-22T17:41:39.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":97},"url":"https://github.com/2684/angular/issues/2684"}