An Api client is an interface that defines a given http api endpoint. We use Refit to make this happen. In the past when you needed to make an http call to an api, be it internal or external, you needed to create an HttpClient, serialize your request object to json, send the request, wait for the response and deserialize the json respone. Refit eliminates the need for that. All you have to do now is define an interface with the methods you want to call on the api and annotate them accordingly so that Refit knows what http method to call, what path to use and so on. Then you simply call the method and the return value is a strongly typed object. You no longer have to worry about HttpClient or serializing/deserializing the response. You can see an example of this in the
IExampleClient interface, that is configured to call into the
ExampleController. More information on Refit is available here.
So why would you write api clients and controllers for your own application? Sometimes it is desirable to put certain operations inside a controller (as opposed to having it in the
.razor page directly), because you may have a mobile app that needs to also call this operation. You then have an http endpoint and both the mobile app and the Blazor app can use the same Refit client to call into it. Or it may also be that you have an external api that you need to call. If there is no Nuget package that provides a way to call into it, you can simply create a Refit interface that mirrors the api endpoints and you'll be cooking with gas in fairly short order.
We have made it extremely easy to create new Refit clients. All you have to do is make sure your client interface implements the IApiClient interface. We use reflection to auto-discover these interfaces and register them with Refit, so you don't have to! Then you can simply inject them anywhere you need them, just like you would inject anything else. For example:
@inject IExampleClient ExampleClient.
You may wonder how authorization works for all the http clients. If you look in the
AuthorizationMessageHandler middleware, you will notice that it is setting the Cookie before each request if there is one. That cookie comes from
_Host.cshtml by way of the
HttpContext. Because Blazor uses a fundamentally different runtime model than traditional Asp.Net Core applications, it has certain constraints, one of them being that you can't access HttpContext from Blazor code. You must do it in
_Host.cshtml( which is actually just a regular Razor page). You then have to pass down context information to wherever you may need it. . Here we leverage the
AppStateService to store the authorization cookie, as well as he user that is logged in. See how that is done in
App.razor in case you need to inject more parameters. The whole mechanism is a bit clunky and we are hoping that Microsoft will address this deficiency in a future update. For more information, see this.
Table of Contents
- Initial Setup
- Project Structure
- Entity Framework
- User Interface
- Email Service
- Background Workers
- Creating a new Page
- Publishing to Azure