This article shows how to host an entire web API stack in memory for testing using OWIN:
http://www.davidwhitney.co.uk/Blog/2015/01/07/testing-an-asp-net-webapi-app-in-memory/
Whereas this article shows using the OWIN TestServer to unit test controllers:
https://blog.jcorioland.io/archives/2014/04/01/using-owin-to-test-your-web-api-controllers.html
The difference I see is between the use of TestServer.Create and WebApp.Start<Startup>
What is the key difference and why would you choose one over the other?
Is it simply the difference between unit testing controller methods as web api calls versus end-to-end integration testing in memory?
When you do
TestServer.Create<Startup>() - you start just the in-memory instance using your startup file. The HttpClient that is inside TestServer is enough for integration testing in-memory. We are starting all the testservers inside one process, so this is not a limitation (currently 4 test servers are running together).
When you do
WebApp.Start<Startup>(Settings.WebApiUrl) - you start a web app on the url you provide. There is also another overload which accepts options: both urls and settings.
We are using this option only for specific cases. Such as:
Hosting url for SignalR client - it won't work without the URL,
where it could run
Contract based testing - verification of the contracts on provider
side. This also can be done only through started WebApp. (We're
using Pact.Net)
Related
I have a sample web API hosted in an OWIN process (self hosted, not in IIS). I get a JWT token in my controller and I want to be able to retreive it in another part of the application, a class that implements NserviceBus IMutateOutgoingTransportMessages. In my other web application POC (hosted in IIS), I used a simple session variable and it works just fine. But I'd like to know what would be the best way to do it in my new OWIN self hosted environment ? Static property in static class ?
This question is really broad and difficult to answer without detailed knowledge of your specific needs. Here's my interpretation of your issue:
You're already signing each request, perhaps storing the token in the browser sessionStorage (or even localStorage), but this does not suffice
You need to retrieve the token outside of or not in relation to any request cycle (if not, this is probably where you should be looking for answers)
Your application does not need to be stateless
Just one static property for one token in a static class would of course start breaking as soon as more than one request hits the application at the same time. Implementing a class that maintains a list of tokens may be a solution, although I can't tell what key you should use to identify each token. Interface details would vary depending on things like if you need to retrieve the token more than once.
Thread safety issues would apply to all handling and implementation of such a class. Using Immutable Collections and functional programming practices as an inspiration may help.
If lingering tokens poses a problem (and they probably would from a security perspective, if nothing else), you need to figure out how to make sure that tokens do not outstay their welcome, even if the cycle is for some reason not completed.
Seeing how you used Session as a solution in your POC, I'm assuming you want some similar behavior, and that one user should not be allowed to carry two tokens at the same time. You could store the tokens i a database, or even in the local file system, making maintenance and validity a separate issue all together.
There are implementations of cache-like functionality already available for OWIN self-hosted applications, and maybe one of those would serve as a shortcut to implementing everything yourself.
If this token business in fact is the only reason for introducing state in your application, then the best solution IMHO would be to rethink your architecture so that the application can remain stateless.
I'm facing a similar dilemma on a server i'm currently developing for a customer. My problem is that the server must make calls (and retain a live connection) with a legacy, multithreaded DLL, (aka the SDK).
I struggled to get this working on IIS with a regular Web API project. Failed badly since IIS recycles threads when it determines that a thread is going rogue... witch is what the SDK thread looks like in that perspective. Also, the SDK must be able to callback on the caller (client - single page app) and for this I'm using SignalR.
I then tried a multi-part system (single page + web api on IIS + WCF service for the SDK integration). But it is a real nightmare to manage because of the 2 way async communication that must occur between all apps. Again: failure.
So I reverted to a single self hosted OWIN + WebAPI service in a console app (for now). My problem is that some of the calls are lengthy and are processed in a worker thread. I managed to pass the SignalR client id in each ajax calls via headers. I can extract the id when in web api controller. But when the task goes async, I need to get the id (via an Unity injected service) from the class that manages the async task. This is where my problem is similar to yours. In IIS hosted apps, we have HttpContext. It is contextualized on each client calls, and follows any thread changes in the pipeline... But not in self hosted OWIN WCF apps...
I'm looking into Thread Local Storage, CallContext... and other means of keeping track of the original caller info during the lifecycle of the async call. I have read about OWIN pipeline, I can capture the info in a OWIN middleware... but how to safely keep that info for use in injected services? I'm still searching for an answer...
I was wondering if you have found a solution to this rather interesting problem ?
I prefer adding to your thread rather than start another parallel thread / SO question.
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.
Say I'm building two applications:
1) A public website
2) A service
The website can be accessed, of course, by users.
The service can be consumed through a web API, but will also be consumed by the website.
This means that common functionality can be put in the service only, rather than having it duplicated in both the website and the service.
Now, when deploying this solution, there seem to be two options:
1) Have the website directly reference the web-service, and deploy both binaries to the web-server, running in the same process.
2) Have the website reference the web-service through the web API, just like all the other consumers. Have the service run in a separate process.
Option 1 would probably be faster for performance, but would require having the two DLLs deployed separately.
Is there any way I can have option 2 (separate processes) but still link the Website to the Service directly, to avoid network latency, serialization, etc?
What technology are you using for your web service? If you're using WCF you can use the NetNamedPipeBinding for your website which is almost as quick as using a dll directly.
I have to integrate with a third-party web-service (behind firewall), and I do have their WSDL and proxy class.
I want to develop the client stuff outside the firewall.
What is the best approach to mock the web-service to ease integration with them?
Do I create a web-service project on my side? Somehow use their proxy classes ad mock the methods? This would create the service references so I can just change the target URL when the time comes.
Or do I create a service layer that returns mock classes in my dev. environment but would use real web-services at run-time?
The former approach would take a lot of work, I would think.
Any ideas?
With just the WSDL, you could host a mock service using soapUI.
I've used the latter approach to good effect in our projects. I've usually found that my apps use a subset of the functionality exposed by a given web service's API, to it's usually made good sense to expose a simpler API to my client code that's more streamlined and that reflects the workflow of my client better. So, since the way I typically use web services already involves writing an abstraction layer, replacing the endpoint on the other side of my adapter classes with a mock service is a very low-friction way to test interaction with the service.
I'm implementing a WCF web service based on WF. This web service consumes other web services which I'm not in charge of. So basically my service workflow contains several Send activities.
I'm following the TDD approach, so the service implementation is to be covered by unit tests. I want to test proper invocation of 3rd party services.
In a non-workflow case I would mock the external services via NMock. But in my case I cannot control the instantiation the workflow instance and I have no idea on how to trick the Send activities to use the mock objects instead of real services endpoints.
Although Unit Testing Workflows And Activities article on MSDN mentions mocks I couldn't find any complete example of mocking the remote end of Send activity.
Any idea on how to do that?
please try Moles framework. http://research.microsoft.com/en-us/projects/pex/
There are samples about how to mock the sharepoint service. I believe the same trick should apply to WF workflow.
I have tried to mock the sqlconnection, Entity framework, web service call, it works very neat. Basically, it can mock almost any .net objects.
Using ServiceAgents wrappers for your web services would be one possible way of doing it.
This is a pattern i have followed in previous projects of mine.
Since they are interface based, you can easily mock out the services.
There are other advantages to this pattern (besides unit testing) including being able to abstract your application from external dependencies to a certain extent. However it does add the overhead of creating another class layer on top of the services.