ASP.Net MVC Web API provides a straight forward controller based approach to creating RESTful HTTP based web services. It should be quite familiar to anyone with an ASP.NET MVC background. This tutorial won’t be focussing on what is and what is not RESTful, (there’s plenty of that already, and can get a little religious!).
Outcome
By the end of this post we’ll have created an ASP.Net MVC 5 Web API Project, and a new Controller ready for implementation.
Prerequisites
Assuming continuation from UWP Tutorials you’ll need the below, for standalone Web API, you can get away without these.
- Morse Coder Part 17 (or a fork on GitHub);
- Visual Studio 2015 Community Edition;
- Windows 10.
Implementation
Project
We’ll be needing a new Project, create a new Project in the MorseCoder solution called MorseCoder.WebAPI…
We’ll be using the new (at time of writing) ASP.NET 5 Template for our Web API endpoint.
Clicking OK will trigger the creation of our project, and Visual Studio to resolve some dependencies on NuGet packages you may not already have locally.
The ASP.Net 5 Framework is really lean compared to it’s predecessor, with nearly all dependencies being optionally pulled in through packages and configured on Application Start. (Have a dig into the project.json if you’re curious.)
Controller
You’ll have a ValuesController as part of the template, delete that and create an AlphabetToMorseController…
Your controller should now look like:
[csharp]
namespace MorseCoder.WebAPI.Controllers
{
[Route("api/[controller]")]
public class AlphabetToMorseController : Controller
{
// GET: api/values
[HttpGet]
public IEnumerable<string> Get()
{
return new string[] { "value1", "value2" };
}
// GET api/values/5
[HttpGet("{id}")]
public string Get(int id)
{
return "value";
}
// POST api/values
[HttpPost]
public void Post([FromBody]string value)
{
}
// PUT api/values/5
[HttpPut("{id}")]
public void Put(int id, [FromBody]string value)
{
}
// DELETE api/values/5
[HttpDelete("{id}")]
public void Delete(int id)
{
}
}
}
[/csharp]
A few key points for further consideration:
- The Route is being defined via an Attribute, not through method calls to register the route on App Start;
- The Class name is important, it’s convention based, whereby it’s the Controller name postfixed by “Controller”;
- Our Method names match up to HTTP Verbs, again by convention;
- The HTTP based attributes define the contract with how we should expect to interact with the routing from the URI.
At this stage, we’re only really interested in a single method a HTTP Get that:
- Takes a string as input;
- Returns a translated string as output.
We won’t be implementing the translation for now but let’s stub it.
Let’s update the Get method to take a string as our input:
[csharp]
// GET api/values/input
[HttpGet("{input}")]
public string Get(string input)
{
return "value";
}
[/csharp]
Browser
We’re now in a position to give our new Web API a quick test through the browser, you can use more targeted tools like Postman in Chrome, but for our tiny ‘app’ the browser will do fine.
Change the Web API project to our start up app in Visual Studio and hit F5…
In your browser hit the Uri relative to your IIS localhost and port:
api/alphabettomorse/abc%20def
To break that down:
- api – our Web API;
- alphabettomorse – our AlphabetToMorseController (remember it’s convention based);
- abc%20def – our input string to the HTTP Get Method (note the URL encoding to HTML character code for the space).
On putting a break point in the Get Method on the Controller you’ll see your request come through and be returned…
You should be greeted by…
…which as you can see brings the response full circle, surfacing the “value” string that we return from the Get Method.
Summary
Where are we?
- We created a Web API Project;
- Created a new Controller;
- Tested the pipes of our new Endpoint.
This post took a bit of a tangent, so where are we heading?
- Implementing Translation Response;
- Implementing MorseToAlphabetController;
- Consuming our new Endpoint from our UWP app.
- Implementing a LiveTileUpdate;
- Making the app User Experience (UX) more friendly.
