Consider having the following string OData query string:

$filter=(Name eq 'bla)&$skip=5

Would be awesome if you can get the lambda function of $filter. Aswell things like skip, sort field and order, etc.

This would be useful for creating a specific AJAX handler which would filter out a dataset, create Observable data streams (Signalr), etc...

Would be cool if we can extend this parser (get the AST and override parts of the Visitor pattern applied to build an Expression).
Why would you not satisified with only $filter -> Func<T, bool>? Well other collections like (Nhibernate) like to do filtering on a specific way.

http://nhforge.org/blogs/nhibernate/archive/2009/12/17/queryover-in-nh-3-0.aspx

Having only Func<T, bool> as output for $filter would make it too specific.

In the current release of OData Web API, security for queries is applied via the Queryable attribute or via ODataQueryOptions. The current system lacks any built-in method for restricting which fields can be used with the $filter query option. Implementing a trivial list of fields that support $filter is difficult, given that it can apply to relations.

Instead, consider adding a "fluent" configuration API that captures this information at the entity level and allows orderby & filter to be "entity model aware" (for lack of a better term).

For example,
var settingsBuilder = ODataConventionSettingsBuilder();
settingsBuilder.Entity<Order>().OrderByProperties("Id");
settingsBuilder.Entity<Order>()
.OrderByProperties({ "Id", "Name" })
.FilterProperties({ "Id" });

The benefit here is that the settings are stored as a single graph that can be traversed when relations are used. Alternately, the QueryableAttribute applied to controllers & query actions can be pulled out and analyzed as a graph, but its very limiting in enterprise scenarios (no inheritance, difficult to extend, etc)

Note that this request is about the default HelpPage code that is added through Nuget, I can fix the code myself, but i'd love to see it baked into the default code (HelpPageSampleGenerator.cs):

The way the Help samples are created based off the return type of the action is cool: If i return a Person then a Person is created with some nice sample values. But most of the time, my actions return an HttpResponse, because I need to control the headers/status codes. This is obviously considered in HelpPageSampleGenerator, there is a comment:

// Do the sample generation based on formatters only if an action doesn't return an HttpResponseMessage.
// Here we cannot rely on formatters because we don't know what's in the HttpResponseMessage, it might not even use formatters.

I would love for there to be an attribute that I can apply to my Actions that the HelpPageSampleGenerator would check for. If that attribute existed then it would replace the reflected return type of that method.