locked
OData Support RRS feed

  • Question

  • User-1078006942 posted

    I know that the Beta version provides limited support for OData.  Is there a list of the features that are currently supported?  Also, are there plans to add more support for OData before the RTM version?  I am especially interested in returning a subset of the properites (i.e. $select=FirstName,LastName) and returning the total number of records that match the filter when using top and skip.

    Saturday, February 18, 2012 10:47 PM

Answers

  • User1220103879 posted

    The current support of query string parameters is limited to $top, $skip, $filter and $orderby.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 19, 2012 1:38 PM

All replies

  • User1220103879 posted

    The current support of query string parameters is limited to $top, $skip, $filter and $orderby.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Sunday, February 19, 2012 1:38 PM
  • User-1032240251 posted

    More importantly, we are not currently planning to support $select for this version.

    Tuesday, February 21, 2012 10:10 AM
  • User-301000020 posted

    Is there some extensibility point one can hook onto, and maybe add that functionality?

    Thursday, March 1, 2012 9:07 AM
  • User-1455438036 posted

    You can always write your own filter to do that processing. Unfortunately, the OData query parser is not public right now. So you cannot build on top of that. Also, could you please let us know what extension/functionality are you looking for ? It would be a valuable input for the team for later releases :)

    Thursday, March 1, 2012 1:43 PM
  • User-301000020 posted

    Well, it would be cool to be able to have (and advertise) full OData support when you make an API, not just partial support. 

    Initially, I thought it was a bug, since Scott Gu's blog post gives the impression that OData querying just works. At least I got that impression.

    But thanks for your suggestion, I'll see what I can do with a filter then.

    Thursday, March 1, 2012 2:47 PM
  • User-1455438036 posted

    If you are looking for full OData support you should be looking at WCF Data Services.

    Thursday, March 1, 2012 3:14 PM
  • User642461793 posted

    I can't speak for everyone else on this thread but what I'M looking for is OData-like querying and hypermedia in Web API.  I want to you Web API over OData because I'll have control over what the payload looks like (i.e. not all the extra Atom Pub stuff that I don't need) but Web API is currently lacking some functionality.  I don't need it right this minute but a definitive answer about whether ir not it will be in in the final version of MVC 4 would be appreciated.

    Thursday, March 8, 2012 2:02 PM
  • User2069942341 posted

    Select is essential!

    This is designed to work with single page amoung other things.

    If I'm listing data I do NOT want to select * unless I'm editing and even then only a single record EVER.  Any design that SELECT * on a lot of records (i.e. greater than 1) BAD DESIGN.

    In all other cases, select * is just a massive waste of database and bandwidth.

    I strongly encourage you to put back Select because without it there is no point to what you're building with MVC.net 4 single pages view because all of the speed improvements using SPA will be flushed down the toilet without select.

    Saturday, March 10, 2012 2:56 PM
  • User2069942341 posted

    *bump*

    MS PLEASE RECONSIDER THIS!

    You're making it so that we create apps that SELECT * which is against every rule that you've ever preached and against EVERY RULE THAT ANY SANE PROGRAMMER EVER FOLLOWS.

    If you do not fix this, then Web API is completely USELESS for any production application.

    We will not use it and we'll advise anyone that listens not to use it because of this massive performance issue.

    Tuesday, March 13, 2012 12:11 PM
  • User-2045101248 posted

    Did you know you can perform a .Select as the last statement of you IQueryable<T> expression to completely customise the type returned.<o:p></o:p>

    Tuesday, March 13, 2012 12:36 PM
  • User-1455438036 posted

    true. but you cannot do the query from the client. @John Galt: your feedback has been noted down. I will log a bug for the same.

    Tuesday, March 13, 2012 1:02 PM
  • User-635881420 posted

    If you are looking for full OData support you should be looking at WCF Data Services.

    Lookst like WCF Data Services doesn't support $select.

    take a look at this: http://msdn.microsoft.com/en-us/library/ee473425.aspx

    "Query projections queries on the client are translated to use the $select query option in the request URI. When a query with projection is executed against a previous version of WCF Data Services that does not support the $select query option, an error is returned. This can also happen when the MaxProtocolVersion of the DataServiceBehavior for the data service is set to a value of V1. For more information, see Data Service Versioning (WCF Data Services)."

    cheers

    Monday, March 19, 2012 6:13 AM
  • User-1295418606 posted

    I can get $top, $skip and $orderby working fine but $filter just returns a null reference excpetion.  See http://stackoverflow.com/questions/9762064/null-reference-exception-occurs-when-using-odata-in-web-api-calls for more information.  Do you know what I am doing wrong?

    Monday, March 19, 2012 4:20 PM
  • User-1739260477 posted

    Hi

    So $count or $inlinecount wont work i guess. How can we extend the for count filter?

    Thursday, March 22, 2012 6:41 AM
  • User-1620313041 posted

    If you reconsider the select, you should also reconsider the $inlinecount. It is essential to make an "acceptable" paging. While, select can be hardcoded in the server, ...that for most of  practical applications is ok, MOST of apllications needs the total count of records to page data, so omitting the $inlinecount would probably limit drastically the use of the IQueryable feature of WebApi.

    Thursday, March 29, 2012 6:48 AM
  • User-144149134 posted

    You're making it so that we create apps that SELECT * which is against every rule that you've ever preached and against EVERY RULE THAT ANY SANE PROGRAMMER EVER FOLLOWS.

    If you do not fix this, then Web API is completely USELESS for any production application.

    We will not use it and we'll advise anyone that listens not to use it because of this massive performance issue.

    As mentioned previously, $select has no relation whatsoever to the generation of SELECT *.

    I'm really sorry you seem so offended that Web API isn't the new version of OData, but I really don't understand the animosity here. Web API is a terrific product, with several companies already using this (or soon to) in production. It's clearly both stable and scalable. Not all applications are pure data access applications, and Web API is not an enabler of data access on the web.

    Use WCF Data Services. I still don't understand why you want/don't want to use Web API when the solution you want already exists. Web API clearly doesn't work for you, and that's okay. Another tool does what you want.

    Thursday, March 29, 2012 10:57 AM
  • User-144149134 posted

    Since others are making so much noise, I'll throw my vote in: please don't support OData. Maybe take it away altogether. I don't need it, don't want it, and I think it just adds to the confusion. :) If I want to serialize my data, I'll go use WCF Data Services. Otherwise, I will construct my own query syntax, as it should be.

    (Disclaimer: this is tongue-in-cheek, though still true.)

    Thursday, March 29, 2012 11:01 AM
  • User-1620313041 posted

    Personally I think there is no need WebApi implements the full oData....On the contrary I find this damgerous..... Web Api with IQueryable migth be an usefull way to send query to the Server and to handle the results with paging...without the need too write too much code.

    If one uses them with this purpose a full support od oData is just "dangerous", since oData allows operations that might be dangerous on a big amount of data. oData is just intented to expose reasonably small quantity of data on the web....

    On the contrary WebApi might be an usefull tool to build business application.

    That said I don't understand the insistence on the select....You can apply the select on the server...Why one needs to handle the select on the client? Does someone would like to allow the user select dinamically the columns he wants to see?...If not there is no need of the select clause....If yes....than probably the application is not a business application..but just a tool to browse information on the web...then Use Wcf Data Services...that are the more adequate tool.

    On the other side ...speaking of business applicatiosn I find strange that there is no support fo $inlinecount, since the SPA examples includes pagers implementations...and uses webApi...Pagers works better when the total count of pages is known.

    Thursday, March 29, 2012 12:48 PM
  • User956740506 posted

    Please add $count so we can build proper paging solutions.

    Thursday, May 24, 2012 10:14 PM
  • User-162893716 posted

    We really need support for $inlinecount and/or $count. With no efficent way of extending web api to support this I struggle to find a way to add proper paging. I've tried all kinds of more or less nasty hacks to add this. Please add support for this or enable a proper way for us to implement this.

    Friday, May 25, 2012 6:45 AM
  • User1169324036 posted

    We really need support for $inlinecount and/or $count. With no efficent way of extending web api to support this I struggle to find a way to add proper paging. I've tried all kinds of more or less nasty hacks to add this. Please add support for this or enable a proper way for us to implement this.

    I second this, paging features should just be removed if this support isn't enabled. I see that they do have code for it here. But it won't ship until after v1.

    Friday, July 6, 2012 1:44 PM
  • User-1448128321 posted

    You can get $count to work by using Accept:*/*.  It won't return XML or JSON, but text/plain.  Use WFetch to test.

    Monday, August 6, 2012 5:42 PM
  • User2106035892 posted

    Custom extensions ($count) pain in the neck but should work:

    http://www.strathweb.com/2012/06/extending-your-asp-net-web-api-responses-with-useful-metadata/

    http://thedevstop.wordpress.com/2012/04/05/adding-odata-inline-count-support-to-the-asp-net-web-api/

     

    Check the comments from a Ms employee

     

    <cite class="fn">marcindobosz</cite> says:<!-- .comment-author .vcard -->

    <!-- .comment-meta .commentmetadata -->

    Hi David, Great post. I’m one of the developers on Web API and I thought you might like to know that we have some prototype code to support inline counts here: http://aspnetwebstack.codeplex.com/SourceControl/changeset/view/88372a0b4ab9#src%2fMicrosoft.Web.Http.Data%2fQueryFilterAttribute.cs. It’s implemented as a combination of an action filter that performs the count and a special ApiController base type that is responsible for building a result object that includes the count and the results. The feature is not currently scheduled to ship for V1 as part of the core Web API but I hope the code provides some inspiration.

     

     

    Wednesday, September 5, 2012 4:03 AM