I've really enjoyed using Flurl the last year but have encountered a problem that Im hoping I can solve using Flurl if possible and not resort ripping it out and using IHttpClientFactory and HttpClient from System.Net.Http
I've got a DotNetCore 3.1 API and our client is calling these APIs with custom headers. "x-activityid" as an example. My API calls out to an external API and so I've created a separate Client class where im calling the endpoints on the external API using Flurl.
I need to propagate some of the headers from the requests incomming to my API to the requests I make to the external API that Im calling using Flurl.
Some related links:
Header propagation using ASP.NET Core
Make HTTP requests using IHttpClientFactory in ASP.NET Core
The whole idea of header propagation depends on awareness of some HTTP server context from which to grab the incoming headers, which is why ASP.NET Core can support such a feature directly while Flurl, a stand-alone library that often gets embedded in things like Xamarin apps, cannot.
But all is not lost, because Flurl is really just a wrapper around HttpClient. To get this feature to work without giving up Flurl, just wire up header propagation in ASP.NET Core exactly as prescribed, allow it to inject HttpClient instances into your service classes, then wrap those instances with Flurl inside those classes. Note that you'll need to adapt the pattern of using FlurlClient directly, as opposed to building calls off URL strings, if you're not doing that already.
Related
I'm implementing profiler to track http requests coming to .net core applications hosted in IIS. I'm using coreclr profiling api to hook method enter/exit.
Which method I should track to know a new http request coming into my application.
Create a middle ware and configure ASP.NET Core to use it. It should receive requests, process it, then pass it along with the pipeline.
For more information see here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-2.2
The post is almost duplicate as this question, but I am using new SignalRCore (1.0.0 alpha2).
<PackageReference Include="Microsoft.AspNetCore.SignalR" Version="1.0.0-alpha2-final" />
In my .NET Core 2.0 I use OpenIddict to authenticate user on server. On client I use angular2-jwt.
Now I need to know how can I connect on server with Authorization header access_token? I would assume that I should use custom request header when trying to connect on server.
Can this be done with new SignalR Core? I found this thread which mention that websockets does not support custom headers but I wonder if SignalR Core team did some magic to support this scenario.
This is not possible when you are using JavaScript client because some underlying APIs (like webSocket) don't allow setting headers. This is why you need to use queryString. Also, this thread on github may be useful.
If you are using the C# client setting headers is not possible at the moment but this is just a limitation of the API and should be fixed in the future.
EDIT
SignalR now has API that allows to pass JWT token to both C# and JavaScript client. It is also now possible to set headers when using C# client.
I have a solution with an MVC application and a Web API. They're in separate projects and domains (using CORS). I built it as a Web API to have the flexibility for adding consumers but currently my MVC application is the only consumer. As such I'm debating whether to use HttpClient inside my MVC Controller or directly instantiate the ApiController.
In either case, I'm using dependency injection (Autofac) so I'd also like to know how to configure that because neither HttpClient or ApiController have any kind of interface that I can inject through constructor parameters like I usually do so I'm not sure how to handle this.
What should the lifetime scopes be for the injected instance? HttpClient should probably be Singleton since it's not encouraged to dispose it after each request.
NOTE By calls to the API return large datasets used to populate charts which is why I'm leaning a bit away from HttpClient as I feel I will incur additional overhead using Http. Is it an antipattern to directly instantiate the ApiController?
Thanks
You could always do this
var httpClient = new HttpClient(new HttpServer(GlobalConfiguration.Configuration));
This allows you to continue using the HttpClient but the requests get passed directly to the WebApi server without ever making a network request. This way if you later decide to separate out your WebAPI your client code doesn't change
I have a web application (typical mvc webapp) that needs to call a REST API bundled in a different webapp (war file).
The first web app serves as a front to the separate REST API webapp for customers to register and view their stats, purchase plans etc. But part of the design of this webapp is that it must have example invocations to the other REST API webapp.
There are many rest clients out there, but what would be a reasonable approach to address the above?
I was thinking of using the Spring REST Template to call the REST API but from my mvc controller class in the first webapp. Is this a reasonable approach?
Once you deploy a webapp using your deployment tool of choice, you can simply call the REST URL. That's one of the great things about REST - it doesn't care about what sort of tool is calling it because it deals in a neutral medium (usually HTTP). Twitter's REST API (here) doesn't care what's calling it - in fact the beauty of it is that anyone can make an app that calls it.
So say you deployed a webapp locally to port 8080, you can just make a REST call to http://localhost:8080/firstapp/rest/foo.
If you're deployed to the World Wide Web, then just call the appropriate domain.
Yes, RestTemplate is a very convenient way for server to server REST calls. Though there are some tricks if you are going to serialize generics.
I am considering building some services using the new Web API that's introduced in ASP.NET MVC 4 (currently in beta version). I am quite clear on the way these services can be invoked using REST which returns responses either in JSON or xml.
However is there a way where I can add these services reference in client application and generate stubs for response objects, similar to the way .NET response objects are created when we add a WSDL reference.
ASP.NET Web API does not have any such built in capability. Short of providing some WSDL-like metadata information that the existing VS tooling could read VS 2010 does not have a way to create a CLR object from a JSON service.
However, another approach you could consider is to create a simple class library with the DTO (data transfer objects) classes that could be used by both the server and the client.