The client I’m currently assisting has begun to move applications from more monolithic architecture into a more modern, cloud-based architecture. The organization is a bit of a .NET anomaly in that it is a company that’s primarily Java, yet has some .NET.

So even though Microsoft has a list of framework tools (such as Azure Service Fabric and Azure App Service), it’s fair to say that asking a primarily Java-focused company to use those tools could be an uphill battle. This is where .NET Standard and .NET Core have come to the rescue.

I work with a ton of smart people and I’m pretty amazed at how fast they can pick up on things from reading. I, however, cannot really understand it fully until I touch it. So let’s build a quick RESTful Web API step by step to see how challenging it is. We’ll be using .NET Standard, .NET Core, and ASP.NET Core.

Brief Introduction

There are plenty of in-depth articles out there that can explain what these technologies are, so I won’t spend a ton of time. But here is a high-level overview:

• NET Standard is an abstraction for standard APIs. It is required for all .NET Platforms to implement this API. .NET Framework, .NET Core, and Xamarin will all have, to use Microsoft’s words, “one library to rule them all.” This will make switching platforms easier. A developer can learn something by working on one platform and can expect it to work the same way on another.
• .NET Core is designed to be operating/platform system agnostic, meaning it will work on Windows, Unix, and/or macOS. It was also designed with a microservice architecture and containers (such as Docker) in mind. There is a focus on performance, scalability and the ability to have side-by-side installations.
• ASP.NET Core is a modern framework for building cloud or internet-connected applications. It’s also cross-platform and can be hosted on IIS, Nginx, Apache, Docker, or self-hosted in your own process. It’s designed to be lightweight, modular, and with performance in mind.

Our Example

This example will be done in Visual Studio 17. The goal is to stand-up a RESTful Web API that can CRUD an Employee. (Yes, I just used an acronym as a verb.)

To start, I opened VS17 and selected a new project. I created an MVC project and named it Employee.

Next, I decided to create the employee controller by right-clicking on the Controllers folder and selecting Add → Controller.

I then choose API Controller with actions, using Entity Framework.

I receive this pop-up, so I enter in what I wanted to call the “everything all-around employee” as that is the microservice I’m creating.

At this point, I’m not able to add with everything filled in. My assumption is that since Model Class is a drop-down that I need to create model first, even though I was able to type the name of the model in there. I clicked on the Models folder and added a new .cs called Employee and tried again.

This time it was successful. As soon as I selected the model, it filled in the name of the controller. I pressed the plus button to get the context filled in.

I probably should have put a little something in the Employee.cs. I went back in and added

 public int Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }

THIS time: success; the third time’s a charm.

Visual Studio scaffolded-in the controller and added a new folder with a dbcontext in it. I noticed that the web.config I’ve grown to love over the years wasn’t present which left me to wonder where is the connection string for the database. There was something called appsettings.json under the project which I where I found the connection string.

Another thing I noticed is that the scaffolding injected the EmployeeContext right into EmployeeController. I’ve always had to add a reference to my favorite DI, container, register, and add it manually into the constructor. It appears to be built-in. Maybe it’ll become the norm and I can stop having the “why you should DI” discussion.

I’m going to use an In-Memory database for the practice project. I found the registration for the context in Startup.cs file and changed it from:

services.AddDbContext<EmployeesContext>(options =>
                    options.UseSqlServer(Configuration.GetConnectionString("EmployeesContext")));

To

services.AddDbContext<EmployeesContext>(options =>
                    options.UseInMemoryDatabase());

Which then gave me a warning that this method is deprecated. But all it was really for was a name.

 services.AddDbContext<EmployeesContext>(options =>
                    options.UseInMemoryDatabase("EmployeeData"));

Okay, time to see if it works. I opened up Postman, my favorite HTTP client tester. Since we don’t have any data, let start with the Post.

In my first attempt I received a bad request 415 Unsupported Media Type because I forgot to add a header.

This time with a proper header, success. Now let’s get the employee.

Okay, now I posted a second employee and the called the get all. I should have two employees.

Now for the put, changing Smith to Smithy.

Calling get all will verify that the name has been changed.

Finally, the delete call.

Just because it isn’t really successful until you verify it, I made the all employee call again.

Final Thoughts

In closing, this process was straightforward. Microsoft does what it does best and introduces versions without dramatically changing the way a developer works. .NET Core feels like a huge leap forward without feeling like you have to relearn everything.

You may still need to use .NET Framework for things that haven’t been ported yet. For example, the client I’m working with has a client that it shares data with using WCF. This isn’t supported in .NET Core. The solution was to create a .NET Framework Web API project that calls the WCF. The .NET Core project can then call the proxy. I know, it sounds like some kind of APInception.

Anyway, hope that you enjoyed this quick look into how to build a quick Web API. This shows a lot of promise to me.