Well hey there!

Now that the dust has settled a bit and I have calmed down after my last blog post, I feel in a much better position to talk about my new dotnet global tool!

Dot net server

In the modern developer world we are working with interconnected systems service A calls service B calls service C, now when you are working on service A what do you do when it calls service B?

Do you spin up a fake service B?
Do you create an API collection in postman?

Let me introduce you to a third option, dot net server - a configurable http server that you configure with a text file (written in json) that will only answer requests on the url's that you have specified with the response code and body that you have specified.

Now you don't have to write/alter code to return a bad request or a specfic response body, just simply put it into the dotnet server configuration file and run this global tool and then allow your service to call.

I believe this will be a great tool for testing SPA applications or any application that has one or many downstream services that it relies on to do it's thing.

Is this only for dot net?

Nope it's just written in dotnet, it's just a simple http server that listens on a port to a specified list of urls and returns a body when that url is hit, nothing intrinsically linking it with dotnet what so ever, this is just the language I know and love and with the recent asp net core changes to add endpoints really cheaply and the dot net global tools I believe this is almost the perfect toolchain for what I wanted to achieve.

Main use cases

• If you are coding a front end and want a configurable back end that you want to respond with different status codes, to test stuff out without having to mess around with actual code.
• If you are coding an api client and want to test out different ways to respond to api responses etc.
• You are developing a service that has a downstream dependency that is expensive to run on your dev box and haven't got a fake version

Why are you writing about it again?

I feel like with my latest release (1.1.0.1) it is in a stable position, and I am deprecating all previous versions, the project I feel is now in a good state for the future and I can build off of it whereas before it was mostly testing github actions and getting things working.

Let me take you down a list of the current features:

• Setup ssl and non ssl ports
  I believe you may have to have the dotnet core IIS certificate installed on your machine to run the ssl ports, but they are there and configurable, so let me know how they work for you!

• Setup get, post, put, delete methods on any url
  Specify a url and a method and the server will listen out for that particular request!

• Setup a json response
  This is where I am going to be focusing most of the future development right now - more on that later, but right now you can specify a response code and a json body and when the server receives a call on the url specified in the request it will respond with the same response over and over.

• Setup headers
  This is just a key value pair of strings but worth throwing out that you can now specify headers if your client is looking for specific headers on the response.

The future?

As I say I'm thinking on concentrating on the response stuff for now - I feel like there's a lot to add there, I've made it possible to extend this so that I can have a fromFile response, where you could possibly specify a file to load contents from and that will be the response, another example could be a response from string, maybe your client expects a string result and not json, that's completely possible so I'll add it.

There are other use cases in my head like what if you want to test out retry logic? well we could throw in a success rate for the response (or failure rate) where you can sepcify a percentage chance that it will succeed/fail, or maybe you want it to respond after a certain amount of time, or have a list of responses and it keeps iterating through them one by one, or randomly from the list.

So many cool ideas to play around with in the response space I think.

I have some ideas around the request aswell, like what if you want to say if I see this type of request (something silly llike if I see a key "Foo" with the value "Bar") I want to respond one way, but if I see the same key with a different value then I want to respond a different way.

So many ideas floating around in my head for this project I think.

If you want to give this tool a try, please download and enjoy:
nuget link

If you're interested in contributing or throwing ideas at me, let me know in my github issues:

Thanks :)