SetPageSize for Web Api OData API support?

Topics: Web Api
Feb 16, 2012 at 2:51 PM

I am wondering if there is support for something like what WCF services support in respect to setting page sizes. For instance, with a WCF service I can set DataServiceConfiguration.SetEntitySetPageSize to limit the number of entities returned by a API method and then I can handle this on the client-side. Is there support for this in the current release of WCF Web Api? I have not been able to find anything related to it.

Feb 16, 2012 at 3:17 PM

Use OData. There is an example in the examples given by WebAPi.

It's also in the "getting started" example.

Feb 16, 2012 at 4:18 PM

Thanks for the response.

I am using OData. Basically, I am returning an HttpResonseMessage<IQueryable<T>>. Works great for filtering, ordering and what-not.  But, what I don't know is how to set the maximum page size for the results returned in the IQueryable and whether there is a continuation token automatically returned to the calling client. Is that in one of the examples?

Feb 16, 2012 at 4:50 PM


Feb 16, 2012 at 4:53 PM

This won't really work efficiently unless you are using EntityFramework because that implements IQueryable. I don't know of any other ORM that supports it.

You would have to write in support for OData yourself, if you want to use it, efficiently. You have to support all the query options and build your data queries appropriately. It ain't so bad using something like an ORM, but if you are doing plain SQL/SPs you will have a real hard time.

Feb 16, 2012 at 5:46 PM

Thanks for the additional responses.

I think maybe I am having a hard to wrapping my head around this. With a standard WCF Data Service, I can create a DataService with a DataContext and that would expose those context entities via OData. I have done this with an Azure TableServiceContext, to expose table storage entities via OData, which was quite convenient, although a but cumbersome. I was wondering if there was a way to do something similarly with Web API. Maybe that is my mistake. I should maybe just be using standard WCF Data Services to do what I want to do.

So, even if I created a TableServiceContext and returned an IQueryable property (that is created using CreateQuery<entity>) from that context in a GET WCF Web Api method, I don't know how to control the maximum number of records returned or whether a continuation token will be returned. WCF Data Services configuration had a method that I could call to set that value for the service, so I think that is all taken care of for me. I can control it on the client-side, as you suggested, but that's probably not very efficient.

Feb 16, 2012 at 5:56 PM

Pretty sure that DataContext is LINQ to SQL, another ORM. I forgot about that one (dunno anyone who uses it cause the SQL it generates is horribad)

That would work too.

You need to understand the WebApi is the interface for extending your code to the public. By them saying they "support OData" it meerly means they translate the OData query options and invoke the appropriate stuff onto your IQueryable object. 

Your IQueryable still must properly support all the query options. WebApi does not go to your database, the IQueryable does.

Do you mean you want to prevent the user from EVER specifying over a certain amount?

It's hard for me to translate because I have never used "SetPageSize".

It sounds more like this is your question:

"How do you prevent users from requesting too many records when implementing OData?"

For that... all I can say is create a request handler, set a breakpoint, and inspect the input and output parameters on the HttpRequestMessage when doing an OData request.
I would guess the only way, would be to read the proper input parameter (the top part), insert one at the max, if one does not exist, or set it to the max if its greater than the allowed value.

This is similar to how you can force media types. You make a message handler, remove all the accept properties from the headers, and add the ones they must support. (This is how I force every request to be JSON) 

Feb 16, 2012 at 6:04 PM

Previous suggestion meerly speculation.