You are testing, right? Have you ever used a mock in your test? When testing a class, a mock allows you to create an object that looks just like an object that your class depends on, but acts in a very specific way that you specify for your test, so that you can test your class completely isolated from the rest of your code. If you’re not familiar with mocks, visit Moq’s quickstart guide to get started.

Now that you know about mocks, let’s look at mocking something a little more complicated. If you’ve ever wanted to unit test a method that uses a DbSet<T> to retrieve data, it can be challenging to figure out how to properly mock the DbSet<T>.

Read More

Microsoft’s ASP.Net Web API 2.2 allows you to easily create REST style APIs on an IIS website. Microsoft has some great documentation on how to get started with it, so I won’t rehash that here. Instead, I’m going to go a little deeper into some powerful features that can be used with Web API.

• Part 1 - Customizing auto-generated documentation
• Part 2 - HTTP Response Codes
• Part 3 - HTTP Error Codes from Exceptions
• Part 4 - OData URL Query Options
• Part 5 - DTO Transformations and Automapper
• Part 6 - Testing with EF Rollbacks across HTTP (this article)

Overview

A few weeks ago I wrote an article called Cleaning Up EF 6 Tests With Transactions Rollbacks, where I showed how to create integration tests that set up some data in a database, run a test against the data, and then roll back all changes to the data. The rollback was possible because all of the changes to the data were wrapped up inside a transaction.

This posts extends that idea, but instead of a test calling methods on a repository or service layer, this test makes an HTTP call against a Web API endpoint, while preserving the ability to revert all changes to the database as part of a transaction rollback.

The interesting part here is that we will create a database context, start a transaction against that context, create some test data, and then spin up a Web API server that uses that same context. When we’re done with our tests, we’ll roll back the transaction so that the database changes are all reverted.

2016-01-27 Update - clarified when Configuration is available in an API Controller

Read More

Microsoft’s ASP.Net Web API 2.2 allows you to easily create REST style APIs on an IIS website. Microsoft has some great documentation on how to get started with it, so I won’t rehash that here. Instead, I’m going to go a little deeper into some powerful features that can be used with Web API.

• Part 1 - Customizing auto-generated documentation
• Part 2 - HTTP Response Codes
• Part 3 - HTTP Error Codes from Exceptions
• Part 4 - OData URL Query Options
• Part 5 - DTO Transformations and Automapper (this article)
• Part 6 - Testing with EF Rollbacks across HTTP

Data Transfer Objects

First, off what is this DTO thing? A Data Transfer Object is an object structure that you use to transfer data across the wire. Sometimes it will look exactly like your entity framework entities. Sometimes it will be different.

For example, suppose you have a database with Customers and Invoices, and your tables look like this:

1
2
3
4
5
6
7
8
9
10
11
12

Customer Table
--------------
CustomerId
Name
City
Telephone

Invoice Table
-------------
InvoiceId
CustomerId
Amount

These are also what your Entity models look like, because entity models reflect the database structure.

Now suppose that you want to provide an API endpoint that returns a list of customers in a particular city with the number of invoices for each customer.

Read More

Microsoft’s ASP.Net Web API 2.2 allows you to easily create REST style APIs on an IIS website. Microsoft has some great documentation on how to get started with it, so I won’t rehash that here. Instead, I’m going to go a little deeper into some powerful features that can be used with Web API.

• Part 1 - Customizing auto-generated documentation
• Part 2 - HTTP Response Codes
• Part 3 - HTTP Error Codes from Exceptions
• Part 4 - OData URL Query Options (this article)
• Part 5 - DTO Transformations and Automapper
• Part 6 - Testing with EF Rollbacks across HTTP

OData URL Query Options

In your API, have you ever created a GET /Orders endpoint, then you discover you need to support paging, so you add an GET /Orders?start={start}&pageSize={pageSize} endpoint? Then you learn another endpoint is needed for sorting by Date, so you also create GET /OrdersByDate and GET /OrdersByDate?start={start}&pageSize={pageSize} endpoints. Before you know it, even though it feels like it should only be a single method, you end up with a collection of endpoints that all do pretty much the same thing except for basic sorting and filtering.

There is an easier way.

Turn on OData URL Query options. To do this, open App_Start\WebApiConfig.cs and add this to the top of the Register method:

1
2
3

// Allow OData Queries on all methods that return IQueryable
System.Web.Http.OData.Extensions
    .HttpConfigurationExtensions.AddODataQueryFilter(config);

Read More

Microsoft’s ASP.Net Web API 2.2 allows you to easily create REST style APIs on an IIS website. Microsoft has some great documentation on how to get started with it, so I won’t rehash that here. Instead, I’m going to go a little deeper into some powerful features that can be used with Web API.

• Part 1 - Customizing auto-generated documentation
• Part 2 - HTTP Response Codes
• Part 3 - HTTP Error Codes from Exceptions (this article)
• Part 4 - OData URL Query Options
• Part 5 - DTO Transformations and Automapper
• Part 6 - Testing with EF Rollbacks across HTTP

HTTP Error Codes from Exceptions

In the last post, we looked at how you can specify HTTP Response codes to return from your API controller when everything is working properly. However, sometimes a problem will occur deep inside your code. Continuing down the REST path, when problems occur, you should use the semantics of HTTP by returning an HTTP status code that reflects the error. When problems occur in your code, exceptions are typically thrown. This week we will be looking at how we can specify the HTTP Response code and content to return depending on the exception that is thrown.

Feb 10, 2016 Update - Fixed bug in second code block

This is a matter of style, but the first thing that I like to do is to create a custom exception, so that I know that what I’m doing will only apply when I specifically raise my custom exception.

Read More

Microsoft’s ASP.Net Web API 2.2 allows you to easily create REST style APIs on an IIS website. Microsoft has some great documentation on how to get started with it, so I won’t rehash that here. Instead, I’m going to go a little deeper into some powerful features that can be used with Web API.

Part 1 - Customizing auto-generated documentation
Part 2 - HTTP Response Codes (this article)
Part 3 - HTTP Error Codes from Exceptions
Part 4 - OData URL Query Options
Part 5 - DTO Transformations and Automapper
Part 6 - Testing with EF Rollbacks across HTTP

Using Appropriate HTTP Response Codes

When building an HTTP REST API, you should use appropriate HTTP response codes to indicate the status of a response. This uses the semantics of HTTP to communicate the status rather than inventing something new. Here are the three response codes I use most often:

HTTP 200 - Everything is OK
HTTP 201 - Something was created
HTTP 404 - Something could not be found

I only explicitly do this for methods that return a single object. For Web API methods that return a collection, I don’t worry about what’s written in this blog post. That’s because if I successfully return a collection, Web API will by default return HTTP 200 OK. If it can’t find any items, I return an empty collection, which still by default returns HTTP 200 OK. And if there is an error, the error handling filter returns the appropriate HTTP Status code for the error (more details on this in next week’s post).

Read More