Design a Web API

Creating the controller

If the query parameters don’t return a matching value, you have several ways to respond, just as you would any other query. Although you can opt to return a null value, a more elegant and expressive means is to throw an HttpResponseException. The HttpResponseException class has two overloads you can use: The first is to specify an HttpStatusCode enumeration value, and the second is an HttpResponseMessage. The HttpStatusCode enumeration provides several common and intuitive codes, and in this case, the value of NotFound fits both logically and mechanically. Make sure that you understand how to use HttpStatusCode for the exam to return meaningful responses to the client.

Creating the controller

Experiment with calling your Web API by accessing all action methods through their URL. Try passing different values for parameters such as accountId. Also pass an invalid value so you get back an HTTP 404 error (the result of HttpResponseException’s HttpStatusCode).

Creating the controller

There are HTTP actions defined in two obvious namespaces: System.Web.Http and System. Web.Mvc. They both have their use and place in the application, but in this sample, the one in the System.Web.Http namespace is the one that should be used. Because there are some other classes in the System.Web.Mvc namespace, it is incredibly easy to accidentally use the incorrect one, so be careful here! Equally as confusing is the AcceptVerbsAttribute, which also exists in both places. Yet it is important to use the one in the System.Web.Http namespace. So how do you know when to use one versus the other? It’s quite simple! Look at your controller and see what the base class is. If it’s ApiController, you should use the System.Web.Http namespace. If it’s not, use the System.Web.Mvc namespace for them. It’s certainly possible for both to exist within the same project!

Secure a Web API

Preventing cross-site request forgery

If you’re unfamiliar with XSRF, https://www.owasp.org/index.php/Cross-Site_Request_Forgery provides a wonderful and very thorough description of it. A summary description of XSRF is simply when a different website or application (even email links) attempts to access a resource that requires authentication to trigger some action that has some side effect.

How to protect from XSRF

Of course, it’s not required to memorize all the code involved in checking the antiforgery tokens. You do need to make sure that you understand the ideas behind it. Sending two values, one in a cookie and one in the form data, and making sure these values match is the basic idea for protecting against XSRF. A good practice is to create a simple Web API that is vulnerable to XSRF and then protecting it so you understand all steps involved. An example can be found at http://www.dotnetcurry.com/ShowArticle.aspx?ID=890.

Host and manage a Web API

Creating your Web API hosting server

Remember to add the default route when self-hosting your Web API. In a web application, this configuration is automatically created for you, but you should add it yourself when self-hosting.

Hosting services in a Windows Azure worker role

Deploying a Web API to Windows Azure Websites doesn’t require any more extra steps than deploying it to an on-premises IIS.

Consume Web API web services

HttpGet via GetAsync

Make sure that you understand how async and await work. Although they’re not explicitly mentioned in the exam objectives, they’re a fundamental part of C# 5. If you haven’t studied async and await yet, see Exam Ref 70-483: Programming in C#, by Wouter de Kort, or start at http://msdn.microsoft.com/en-us/library/vstudio/hh191443.aspx.

Sending and receiving requests in different formats

To prepare for the exam, you can follow the example at http://www.asp.net/web-api/ overview/formats-and-model-binding/media-formatters. It shows you how to create your own formatter and how to use it.