Not taking previously set headers into account

[dbettini]

The library doesn't take previously set headers into account (maybe RequestOptions in general). In my app, I have overloaded BaseRequestOptions, which means that each instance of RequestOptions instantiated through the app will use that as base. Resource just ignores it and gets empty headers instead.
Also, I have injected another CustomHttp in place of Http:

{
    provide: Http,
    useFactory: (backend, reqOpts, storage) => new CustomHttp(backend, reqOpts, storage),
    deps: [XHRBackend, RequestOptions, StorageService]
}

which also sets some specific headers. These headers are also ignored, even though the injected instance is indeed CustomHttp (checked it).

P.S. The idea with CustomHttp is to use it in separate places instead of providing it in place of Http, does this library support choosing a different implementation of Http at the moment?

[troyanskiy]

Hi!
For the headers you can specify by setting setHeaders or simply create BaseResource class and override getHeaders method, please check here .

To use custom Http please try to inject it into the resource constructor and add the resource to your providers list manually (add parameter add2Provides to disable automatic adding to providers).

@ResourceParams({
    url:BASE_API+"/users",
    add2Provides: false
})
export class UserResource extends Resource {

    constructor(http: CustomHttp, injector: Injector) {
      super(http, injector);
    }
    @ResourceAction({
        isArray: false
    })
    query: ResourceMethod<IUserQueryInput, IUserShort[]>;
}

[dbettini]

Hi, thanks for the explanation!
It would be great if custom http service could be sent as a parameter to ResourceParams, so we could avoid adding providers to the module manually, creating explicit constructors, etc. I may even create a PR for that in the future if I get the time, if it's fine by you.

As for this issue and headers, setting headers manually on a resource is not really something you should do if it works in other places throughout the app without doing it. That's kinda the point of DI.
If you want to affect that resource explicitly, that's fine. But if you want to affect the entire app, then it should be done in one place, and that is actually the purpose of BaseRequestOptions (providing default request options throughout the app).

Injecting RequestOptions somewhere here and taking them into consideration in getHeaders etc. could do the trick. I wanted to do it actually, but after cloning the repo I'm getting ngc errors (and also, angular peer deps need an update as well)...