Is it even a good idea to use OData?

Question

Understanding ahead of time the caveat that "just because a capability is offered doesn't make it a good idea"...

From the looks of it, OData compliant signatures require you return IQueryable.

FOR EXAMPLE:

[Queryable]
public IQueryable<MyModel> Get()
{
    return _repo.GetAll().AsQueryable();
}

However, many articles in the recent and not-so-recent past describe IQueryable as:

• Leaky
• 'Causing Heavy Lifting' example: allows users to grab entire table(s)
• Has security & scaling issues as it allows for heavy modification of the query itself
• Can also cause issues from deferred execution (because of its' queryable nature)

MY QUESTION IS:
Do you feel the capabilities of IQueryable and OData outweight the issues above?

In answering, I would expect people to talk about:

• Why or why not?
• When should I use it?
• Do you only use in some WebAPI calls...or for all WebAPI calls?
• What about individual models which are not IEnumarable objects?

...things like that.

BACKGROUND: I ask not only because of the items listed above. But also because OData is being sold to us as an "industry standard" rather than a tool in your toolbox. So, implementing this would fundamentally change the returns for our WebAPI calls (where I currently work). We would have to go from our own IResult return signature (which is very useful) to IQueryable which seems to have issues (but may also end up useful).

IRESULT EXAMPLE:
At minimum, our return signatures would change drastically. And, I'm told WebAPI call implementing OData wont work by changing "C Instance" to "IQueryable Instance" (which makes sense).

public interface IResult<C>
{
    [JsonProperty(PropertyName = "hasErrors")]
    bool HasErrors { get; }

    [JsonProperty(PropertyName = "errors")]
    IList<String> Errors { get; }

    [JsonProperty(PropertyName = "instance")]
    C Instance { get; set; }
}

Answer 1

Supporting OData querying with Web API doesn't require you to have an IQueryable<T>. Having an IQueryable<T> lets you get there faster and with lesser code. IQueryable<T> has the required abstractions to translate an incoming OData query to a LINQ query. The framework already defines it and there is rich support across various back ends for it like Entityframework, NHibernate, Linq2Objects, RavenDB, Linq2OData etc. So, we decided to have rich support for IQueryable<T> with web API. Agreed, IQueryable<T> is a huge interface and exposes a lot more than what is necessary for OData querying. But it is something that comes for free :).

That said, we have good support through ODataQueryOptions<T> for non-IQueryable case. Check out my blog post about this here

Also, you are confusing OData query semantics with OData. Rich query support is only one part of OData. OData builds on top of HTTP and has various useful features like

• A well thought out application of both REST and HTTP best practices.
• Unambiguos representations of your resources in json and xml.
• $metadata.
• A standard way of describing relationships.
• Rich querying that supports projections, filtering, client driven paging and server driven paging(next page link).
• Big ecosystem.