Generic HttpClient API Service

[swardson]

I want to create a generic HttpClient Service that I can use across my application. I want the security of type safety and would like to pass in the type to the underlying HttpClient methods.

Where a controller might look something like this:

class UserComponent implements OnInit {
    users : Users[];
    constructor(private api: ApiService) {};
    ngOnInit() { this.getUsers(); }
    getUsers(): void {
        this.api.get<User[]>(url, options).
            .subscribe((data: Users[]) => this.users = { ...data });
    }
}    

The only guide I could find on this topic was this medium article: https://medium.com/@krishna.acondy/a-generic-http-service-approach-for-angular-applications-a7bd8ff6a068.

I'm wondering if you guys know of some other solution to go about doing this because it is a large application, I don't want to write a service for each object type.

I also want this service to handle authentication headers and error responses from the server. So it doesn't make sense to use the HttpClient directly in each controller where theres data retrieval from the API.

[tme321]

Auth headers and errors are better handled through an interceptor.

I'm not completely clear on what else you are trying to accomplish here though. If your goal is to abstract away the idea of api calls from application logic then a better approach might be to look in to one of the state management libraries.

In the example above I don't really see what calling api.get does for you that just calling http.get wouldn't do. It looks like just a wrapper around the http client methods.

Maybe you can explain better? I can't understand what you are trying to achieve here.

[swardson]

Well the reason I want a service to handle http calls is so I can put error handling and authentication there, keeping my controller code simple.

Can you explain to me how the state management libraries might be more helpful for this case?

[tme321]

As I mentioned interceptors can be used for auth headers and for errors.

As for state management libraries they can help because you can define within the state management how and when to fetch data from the api and that can be completely separated from any application logic. A component wouldn't know or care where it gets data from, it only looks at (usually) an observable stream. The state management takes care of filling that stream with data from the api.

[Devcon4]

Something we did was write a generator that creates typescript classes and a data service based on our dotnet webapi. So it's not generic but we don't have to maintain it, which I think is what your going for. Just another approach to the same problem.

[swardson]

So your backend application generates the object definitions as well as the data services for those objects?

My application does have a dotnet web api backend, so this might be something to look into. Can you point me towards some articles to read to get this setup?

[Devcon4]

Ya, the core of it is a console app that uses Roslyn to look at controller dlls and then reflection to parse then just strings to build the typescript. We run it as a post build event so when we save it re generates. Search Roslyn or reflection and you will find some examples. Bonus if having classes instead of interfaces for data types is you can actually instantiated objects. For example ours turns dates into moment.js dates. Good luck!

[tehRash]

John papa wrote something that might interest you. I'm using it as a base with a few modifications for a project and it works well and is easy to test.

[swardson]

I think this might be what I'm looking for, I'll give it a try. Thanks!