Paging is a useful concept in any API. Here’s an example of one that I use pretty frequently when making APIs in ASP.NET Web API.
You can download an example project (complete with unit tests!) here: https://github.com/schneidenbach/AspNetPagingExample
The steps we’re going to take to complete this task:
- Setup our paging model.
- Define our entity and API models.
- Create our easy-to-use paging method that will magically turn an IQueryable into a paged set of data.
This example in particular requires AutoMapper, which will allow us to easily map our entities to our returned API models. I also use Entity Framework to store and retrieve data, though that is not the focus of this particular project. For the record – you should ALWAYS use API models (or DTOs, if you prefer) to do work through controllers. Taiseer Joudeh, a Microsoft MVP for ASP.NET, calls it the “model factory pattern” and that’s how I typically refer to it. That, or just API models. (Another way to think of API models: they hold the same purpose as a view model, but they’re not called that cause there’s no views.) It’s a little bit more code up front, but will keep your code clean and enforce separation of concerns in the long run. This has several advantages:
- Lets you control what data is returned to the client.
- Helps avoid binding to undocumented properties on PUTs/POSTs, which can be a pretty big security concern.
- Maintains a separation of concerns. (This object returns data to the client, this object is a database entity, etc.)
1. Create and define a paging model.
We have our PageNumber and PageSize, which should match exactly what you requested (if you requested page 1 and page size 10, you should have a PageNumber of 1 and a PageSize of 10. These fields are included in the event you don’t want to require a page number or page size in your paged API.)
You have some Results, which represents the actual objects being returned.
There is a TotalNumberOfRecords and TotalNumberOfPages, which returns totals for the returned objects. If there are 100 total records and you’re requesting 15 records per page, you should expect that TotalNumberOfPages will return 7 pages.
Finally, one of the most useful properties in this model is NextPageUrl. NextPageUrl makes it very easy to get the next page in the set by providing the URL to that next resource for you.
2. Define your entities and your API models (you do use separate models for returning data, right?)
Note that in this example we are using Entity Framework for data storage.
3. Map them together using AutoMapper.
AutoMapper allows us to easily create the EmployeeModel from the Employee without writing and maintaining factory methods. All properties with the same name from Employee will be set on EmployeeModel. A lot of awesomeness in one little library.
4. Create the paged set of data.
I like to use the following CreatePagedResults method below on my controller base class – it does all of the heavy lifting for you.
A couple of important things to note:
- The Url.Link method assumes that you have the default Web API route called DefaultApi setup in your RouteConfig. If you don’t, you might have to tweak this example to work for you.
- This example uses an extension method called OrderByPropertyOrField which (if you haven’t guessed) orders the IQueryable by the specified property, with a boolean to determine whether or not the order by should be ascending or descending. This string points to a property or field name of the entity type represented by IQueryable. The extension method is below:
Download the completed project here: https://github.com/schneidenbach/AspNetPagingExample