Now we need some data, so let’s call the API we created earlier! This took me a little longer than I had anticipated, so I broke it into a couple of GIT commits:
- Set up configuration/add anticipated view models/Utility classes – Git Code 1
- Location controller index action/view/model hooked up to Web Application Program Interface (API) – Git Code 2
To do this, we need an Hyper Text Transfer Protocol (HTTP) client. In creating anything, I like to ask how it will be used. One school of thought is to make something as generic as possible to promote re-use. The only problem (I have found) with this is that you start asking lots of ‘what if’ questions and you usually don’t have any of those ‘what if’ answers. So, another school of thought that I have become partial too is to only build what you need. If the need arises in the future, that the re-use implementation can be made then. There is the potential of more work later, but later you will (usually) have more firm requirements. I have found that this latter philosophy has had more positives than negatives associated with it. So, what do we need?
I think we need a call for each type of method that exists on the API. So, what is the best way? Let’s start with the GET’s and go from there. We know that the summary page needs a list of locations, so let’s build that. To do so:
- I created the HttpClient.cs class. Ironically, the .NET provider I am going to use is also caused HttpClient. So, to prevent any potential name conflicts, I renamed our client to LocationHttpClient.cs.
- To make a call, we need a host (i.e. API endpoint base url) setup. In .NET core, configuration has changed more than a bit. Following instructions in reference #1, I was able to hook up a host key/value entry and read it into my controller’s constructor.
- I then pass to the LocationsHttpClient.cs class in its constructor.
- I added Utilities.cs to make configuration calls a bit easier in the future and Constants.cs class to handle config keys.
- Something that I want to point out here. If you notice, the Data project has a Locations and LocationDetails model. I am not going to use them in the view. You can, but then your web site is tightly coupled to the DataProject. It may seem like more work, but it having a loosely coupled system is almost always better than having a tightly coupled system.
- If the Data project needs to have a change in its models, that will not break the site. The website models may have to be updated, but one updated doesn’t break the other. Good engineering tip!! This work occurs in GetLocation(). Coming in, the serialized data package is an array of data location models. So, we will need to de-serialize then into that first. The best package I have used many times is Newtonsoft.Json. The data is then converted to the Web Models and passed to the controller. I am also running the Web API and Web Model View Controller (MVC) app at the same time from the same solution. Launching multiple projects in the same solution is a very handy development tool.
- The last section is the private GET method. I will be using this for any GET calls.
If you run the projects (remember, both at the same time), the index page loads with our one location.
If you click on the link, it will call the Details route with the location id (notice the web link in the lower part of the browser on the mouse over above).
I had planned to do all of the web api methods in this post, but it has already gone longer than I had anticipated. So, next post will wrap up the http client calls with the basic Mvc controller actions.