With the advent of .Net Core, web Api have become more common. Apologies to my non-dotnet background friends, but with .net hands-on, its always inclined towards .net. Coming straight to the point, be it Mobile Apps, SPAs (Single Page Applications), micro-services or name whatever, you will see REST everywhere. In background of this post, old kishore kumar songs are running, so don’t offend a bit of nostalgia 😊.
But as in most cases, everyone is so busy in implementing the APIs, many of my friends don’t ever pay attention on how an API be named. Or rather, not an API but the endpoints and methods (hate to call them methods). Well, for an API the problem there is no standard as such, but rather some best practices, that should be followed ‘ideally’. Lets discuss them one by one. Most importantly, in this post shall be talking only on the API naming. I also had OpenApi in mind, but lets leave it for another post. So lets dive in.
Asp.Net Core is one of the gems (I would say) created by Microsoft that has simplified a lot of things and provides a whole lot of things by default out of the box. It based on dot net core which provides inherent capability to run cross platform but to ease out developer life several optimizations were done to enhance productivity.
One such feature is Dependency Injection. Although lately, but Microsoft did included dependency injection as a part of the core product. I have been working Asp.Net MVC since 2010 (or 2011) and started DI with Ninject which was (or is) a wonderful project. During the time I crossed paths with Unity and Autofac during different projects, but more or less the approach remain same. Create a container system, create ‘sort of’ controller factories and then register dependencies. But during all this time one thing that remain constant was additional overhead of creating this shit. So it was a moment of joy (atleast for me) when i say this in recent versions of MVC. And most importantly it is quite stable and performs well out of the box.
< 1minute to readAzure Application Insights provides a detailed Telemetry about the Application during its lifecycle. It can manage all details for application from Exceptions to CPU and Performance Counters.the level of Instrumentation is completely customizable.
In this Podcast, we plan to have a base understanding, with a short demo including the setup and and configurable alerts.
Please ignore the little not so good sound quality issues because of bad mic. will try to fix in next podcast.
Managing the configuration data have always been troublsome. Although Microsoft did provided and also updated/upgraded a lot of options from time to time, yet it remains a challenge most of time. Things get more critical when the configuration data we are concerned is the confidential data like connection string, smtp passwords, API keys etc becase at some point of time, they do get checked in source code or shared across other developers. In one of my prev project faced a similar issue when private key and the Code Signing certificate was accidentally checked in by a developer. The customer had to revoke the certificate which invalidated all the production builds which were deployed to end users as well.
The Solution: ConfigurationBuilder()
With ASP.net there are some pretty cool enhancements that Microsoft added especially with the Configuration Builder. Earlier whole of .net relied on System.Configuration Namespace to get the configuration data. With the current version it has been greatly re-architeced which now provides a simple key value pair from multiple sources prebuild or even custom providers (like azure or mongoDb) which we shall try out in next post.
By the end of First project we already have a WebApi Self Hosted in Windows Service, but on HTTP. In this post i shall try to add a SSL layer over the top if it to provide additional transport layer security. Things are much easier with IIS, which provides default and simple settings and configurations for all settings like SSL or others.But moving things out of there can be a little tricky. Also, in this post, we shall not be using the developer certificate generated by the IIS, but an actual one issue by CA. For this we shall first register an CA Certificate and then SSL. So let’s roll.
We shall be using the following tools provided by Microsoft that can be accessed from developer command line tools.
netsh (provided by windows)
PS: If you can get a proper SSL Certificate from a commercial CA, you can directly move here.
Creating the CA
All the certificates are issue by Certifying Authority or a CA. So for creating an CA, fire up the “Visual Studio Command Line Tools” and run as administrator. I would recommend create a new folder and browse to that so that things dont mix up.
Type in the following command to generate a new CA certificate.
4minutes to read readWith the introduction of OWIN and self hosting, microsoft has really opened a lot of possible doors for developers and application users. This post is targetted to have an OWIN application hosted in Windows Service. Also we would be configuring the SSL for the Site.
This is pretty straightforward. In visual Studio, Create new project and select Windows Service as project. This will add a project with default Service “Service1”. Rename to whatever the name expected.
Add OwinSelfHost and WebApi2
In the Tools-> Nuget package Manager -> PM console type in the following command to get the WebApi and self host packages referenced.
This will install and reference all the required packages and dependencies. Also we need one more package to debug and use some functions like welcome package. For this import the Microsoft.Owin.Diagnostics using PM Console.
Also, to Enable Cross Origing Resource Sharing, we need to import the following package: