Support setting http headers, both global and request-specific

[egaga]

Apina endpoints don't allow specifying http headers.
This should be possible, either by setting a http header for all future request, or each specific request.

The motivation here is that http headers are often used to pass information that is handled in the backend by some global handler (perhaps by filter or interceptor) unknowst to the specific request handler. Good example would be a http authorization header.

(Possibly optional) header should be declared in the backend code but it should be up to the programmer whether the request specific handler knows about the header. e.g. it should be possibly to declare a header outside the request handler, e.g. in some ApinaHttpConfiguration class.
Maybe the header could also be specified in the request method handler, similar to @RequestParam.

FWIW, it's currently possible to create a custom apina context that sets some http headers based on global state but you cannot add the header info directly to apina endpoint call.

Would it be a good idea to have a proper support for this in Apina?

[mohamnag]

I'm not sure how else is Apina supposed to support header based authentication systems like OAuth & co but in my case where two headers are sent to server for authentication for each request, such feature is definitely necessary.

[komu]

At some point, I might provide a higher level functionality, but currently you have two options:

1. Implement Angular's HttpInterceptor. See for example this article. Apina should pick up the interceptor since it delegates all requests to Angular's HttpClient.
2. Implement your own ApinaEndpointContext (see API call's error/exception handling #40 (comment)).

I would recommend the first option because then your authentication logic is not tied to Apina, but works on manual HttpClient-calls as well.

[mohamnag]

The interceptor seems good enough.

I'm thinking maybe a more detailed documentation will help angular non-profi, Java devs like me feel better using Apina. If you are ok with that, I can prepare a github page based one.

[komu]

Yeah, more detailed documentation is certainly needed. I've already implemented technical pipeline for building and deploying documentation (see my other project's reference documentation), it's mostly just the matter of actually finding the time to write the text itself.

So if you'd like to contribute some text for the documentation that would be great. But of course that's a tall order. 😄 But it's great that you ask questions, since I'll know what the documentation should cover. So please, send questions and tell what things were hard to understand and I'll try to find time for improving the documentation.

[mohamnag]

ok, then when you have all setup for docs, I will contribute by asking and maybe later if you have it online by checking and reporting errors ;)

[stiofand]

Im facing a similar need here. I wish to use the HttpInterceptors myself. However, these only respond to Angular's HttpClient Module not the old Http. Our Apina context class appears to use the old Http for requests. I am at a loss as to how to update our configuration to use the new Modules.

I can see you suggest overriding the Context class with a custom, but how would this class then used extensively in our App where needed?

I thought perhaps the context adjustment would be in the Gradle configuration, but I cannot see how it knows to inject Http into the constructor and not HttpClient?

Any help would be much appreciated.

[komu]

Hi Stephen,

Are you using the latest version (0.10.5) of Apina? It should only support HttpClient and does not support Http at all.

When you refer to "our Apina context class", do you mean the context class generated by Apina or do you have a custom implementation? If it's generated by Apina, then regenerating with a the latest version should be enough. If you have a custom implementation, then you need to tweak it a bit.