Hacking $select into Web API

I really want to use Web API but right now it's broken as in can't ever be used in production broken.

That is that it doesn't support $select so you're always select * and you're always returning full objects. (Amature hour at the zoo!)

So $select is just a parameter on the querystring.

And if I could either bind that to a parameter on the method (can't because of the $ right?) or exclude that parameter and have it still match and just get it from the Request.QueryString then I can use linq dynamic to fix this oversite and just return dynamic.

Then when someone at MS comes to their senses and realizes that this is a bad idea and enables $select it's just a matter of removing the extra method and all of the regular ones will work just fine. (or whatever syntax that they require)

Thoughts on how to do this?

Re: Hacking $select into Web API

John Galt
I really want to use Web API but right now it's broken as in can't ever be used in production broken.

I'm not so sure that's true. We considered having that feature but decided not to support in V1 for a variety of reasons.

John Galt
when someone at MS comes to their senses

Unfortunately we have to consider deadlines, costs, performance and/or security considerations as well as the opportunity cost of implementing this instead of any number of other desirable features when prioritizing work. We certainly have this on the list for vNext.

John Galt
Thoughts on how to do this?

A couple of options. You could use http://msdn.microsoft.com/en-us/library/system.web.http.valueproviders.valueprefixattribute.prefix(v=vs.108).aspx to work around the '$' in the name issue.

Or, you could write a custom http://msdn.microsoft.com/en-us/library/system.web.http.filters.actionfilterattribute(v=vs.108).aspx that could read the query string parameter and dynamically modify the IQueryable content value.

Re: Hacking $select into Web API

I'm sure you and @marcind have some clue about what you are talking about, but I'm totally lost. Is $select some part of the OData query syntax? I have found Web API very useful for production scenarios and hope to roll some items out soon. I also have no love for OData, so that may be why I don't understand any of your points above, if that is how $select relates.

If you are using OData, why not just use OData? How does Web API factor into your platform decision? I'm very confused by your seeming animosity towards the library and the team.

Re: Hacking $select into Web API

Thanks for the suggestions I will look into them.

However I strongly disagree with your assessment that this isn't an absolute requirement for V1 and that it can be used in production as it is right now:

1. Microsoft's own documentation on SQL Server says that Select * should never be used except in extreme situations because of the performance degradation. (there is even an example of doing an join with select * on both parts of the join as to how aweful it is on performance)

2. To do a joined resultset to display a list of say contacts and their phone numbers (pretty common and a common pattern for orders, invoices and just about anything else from a relational database (i.e. ef)) you would have to do a select * on the contacts that you're returning AND SELECT * ON ALL OF THE PHONE NUMBERS. Versus a projection that would return say ContactID, Name, and the Phone Number from the referenced table. Of course this gets expodentially worse as the size of the resultset goes up, but you get my drift about the absolutely horrible waste of both bandwidth and processing power.

THUS

WebAPI in it's current state leaves one of three choices:

1. Hack it like I am so that the client can control the projections as should be the case.

2. Write a million methods for every permutation and combination of select query that your site or api request could want in the way of fields.

3. Dont' use it and go to something that doesn't force you to write crappy inefficient code. (i.e. the technology that this is supposed to replace!)

Obviously #2 is a non-starter in any large production environment because of the overhead of doing so and the maintainability is almost 0.

Thus unless MS fixes this and adds $select support we're left with hacking it in ourselves. (which is exactly what other people are asking about on stack overflow etc.) or ditiching Web API until some indeterminant point in the future when MS comes to its senses.

You guys need to sit down in a meeting and be real with yourselves and admit that for this to be at all useful and not a typical Microsoft half-baked V1 product that won't be usable until V3, you must have the ability to return projections specified by the consumer. Otherwise you're going to end up with either really crappy slow apps that don't scale and people are going to blame MS for why they're crappy and slow.

and/or

0 uptake on this because any educated database person is going to look at what this is doing and put a stop to it immediately and go back to the old technology that actually works (WCF Web API with FULL OData support which this is supposed to replace and make easier)

As for your considering of other factors, you list performance. EXACTLY. Any real world application will have AWEFUL PERFORMANCE with this technology.

And while you also list security, that's a non issue because of the nature of linq. Simply filter it on the server side by the l/p from web forms so that no matter the projection it only returns data that is available by security permissions.

Thus this, as usual with MS, comes down to DEADLINES instead of getting a product right. I strongly suggest that instead of rushing half-baked unusable stuff out the door like MS normally does for V1, you push the deadline by a week or two and put in projections with $select.

(And quite honestly, I don't have a clue why anyone in MS would ever find it acceptable to release a product that is this brutally inefficient and encourages (REQUIRES!) such incredibly bad design that goes DIRECTLY AGAINST your own development guidelines: Only get the data you absolutely need only when you absolutely need it. Data access is the most expensive part of ANY programming. You can optimize your string commands and loops all day long, but a query to the database will ALWAYS cost more than essentially every other operation in programming. Thus to REQUIRE that the data fetch be inefficient to start, and then REQUIRE that all of that useless information be sent over the (low speed) wire is rediculous. And given that displaying lists of data is probably 80% of most applications with CRUD being the other 20% this is the FIRST case you should have optimized, not the last.)

Re: Hacking $select into Web API

Web API uses OData for most of it's responses. It's the core of the system. Yes you can do things like returning a pure string and even dynamic etc. but the power of the system lies in the ability to page, sort, and SELECT against your data source.

Any SPA or indeed anyone using WebAPI is going to need projections approximately 80% of the time given that the average project will display lists of data about 80% of the time and CRUD about 20% of the time (Microsoft's own numbers when describing the power of OData!).

Thus the correct way is to request a projection against a data source that returns the exact information you want from the datasource and nothing else. As I used in my other post, if I want all of the Phone #s of a contact and I want to display only I would Return Contacts.ID, Contacts.Name, ContactPhoneNumbers.PhoneNo. This results in a small data set that is quick both for the Database Server AND for the transmission over the wire and is memory efficient at every level.

However this is what Microsoft requires with WebAPI in the most common scenario of programming anything hooked up to a database (list data): Select Contacts.*, ContactPhoneNumbers.* FROM Contacts INNER JOIN ContactPhoneNumbers ON Contacts.ContactID = ContactPhoneNumbers.ContactID

Instead of returnning 3 columns of information you've returned every column in both tables. Given that the average contact table will have probably 20-30 columns and the Phone Number table could have 7 or 8, and likely there is a note field on the contact that will be nvarchar(max) and could have a 2000 word essay written in it in HTML, you've now taken a paged source of 10 records from a few K from the server and over the wire to several hundred times that. Further the more results, the expodentially worse it gets.

And this doesn't bring up the memory usage issue. The SQL Server has to load all of that data into memory, then WEB API has to load it into memory once from the SERVER and then likely another time to stream it in their json/xml writer implementation. Thus your web server is going to have memory issues FAST and so will your sql server (any SQL admin seeing what's coming over the wire with Web API will quickly put a stop to it's use for this very reason, to say nothing of the guys paying for your bandwidth and your customers on less than optimal internet connections who will see a brutally slow app)

Thus MS is making excuses for why they're not supporting the most important operation there is, second only to WHERE when using a database. And the result is going to be crappy, slow applications that don't scale -- Or people simply won't use it.

And yes, this is supposed to be the long term replacement for WCF OData Services (WCF Web API is it's official name and this is just ASP.NET Web API for a reason).

Hence my frustration. I have to use the old, brutally complex WCF Web API for the new project I'm working on because MS won't get their replacement for WCF WEb API right until V3. Then when V3 comes along I'm going to have to completely retool the guts of our app and likely break our own client implementations AND third parties using our API because MS will have depreciated WCF Web API when they release Version 1 of ASP.NET Web API leaving it the bastard child that will lose functionality support in VS.net much like they did with WSE when they brought out WCF, even though WCF to this day still doesn't support major parts of WSE several versions later (Shared Secret with encrypted communication without having to have an expensive x509 certificate anyone?).

Same old MS routine. Did it with Linq to SQL, did it with WSE, did it with WinForms (same as VB 6 stuff and thus broken from day one) to WPF To Silverlight, etc. etc. etc: Good implementation of something but gets unwhiedy as versions go by because of the lack of forsight originally, ditch it for something new, but the something new isn't really done and doesn't really replace the old stuff, but support for the old stuff that actually worked, even if it was brutally complex goes away. Then we're left with busted stuff that we have to hack to work until MS finally fixes it and puts in all of the stuff they missed the first time, but then the cycle continues.

Wash rinse repeat.

I understand that things evolve over time and you need to adapt and new technologies come along. What I don't understand is MS's ability to accept major breaking issues and push them out the door anyhow because of some timeline. It's the core difference between Apple and Microsoft. SJ released products when he was good and ready and he liked the results and it worked as intended. Microsoft releases them for beancounters whether or not their ready and work in the scenarios that are clearly required. SJ added new features that were world changers, not new features that should have obviously been required for the previous version. (i.e. the addition of the app store to iOS back in the day)

Next stop the completely unfinished Windows 8 that breaks the usage of all power users of desktop computers because they are not going to actually address the core issue of replacing the start menu with something that's actually usable in this scenario. Tech geeks will get pissed off just like they did with Vista, adoption will be horrible on all things other than tablets and maybe laptops because the geeks will tell all of their friends that it sucks and to stay away and MS has another Vista on their hands. Windows 9 will address this glaring issue that a billion 3rd parties have hacked into the OS and made the OS flaky in the process and tech geeks will like it and it will get wider adoption... if MS hasn't outright lost by that point simply because they think they need to hit an arbitrary release date instead of making a really great product that really works for the scenarios it's designed for.

Apple is almost a trillion dollar company. Meanwhile Microsoft has 0 growth and 0 increase in stock price as a result since Bill Gates left. This is why and it's too bad.

Re: Hacking $select into Web API

John Galt

1. Microsoft's own documentation on SQL Server says that Select * should never be used except in extreme situations because of the performance degradation. (there is even an example of doing an join with select * on both parts of the join as to how aweful it is on performance)

The support or not of OData's $select has nothing to do with whether the query to the SQL Server uses "select *".

John Galt

2. To do a joined resultset to display a list of say contacts and their phone numbers (pretty common and a common pattern for orders, invoices and just about anything else from a relational database (i.e. ef)) you would have to do a select * on the contacts that you're returning AND SELECT * ON ALL OF THE PHONE NUMBERS. Versus a projection that would return say ContactID, Name, and the Phone Number from the referenced table. Of course this gets expodentially worse as the size of the resultset goes up, but you get my drift about the absolutely horrible waste of both bandwidth and processing power.

You as the developer are free to make these choices yourself, using C#/VB code. Supporting $select implies that you want to give that choice to your end users. We discussed this possibility, but for time and security reasons, we aren't planning to ship that in v1. I suspect the community will probably supplement our IQueryable support to include things like shape-changing with $select.

John Galt

1. Hack it like I am so that the client can control the projections as should be the case.

While I agree that $select can be useful in some cases, I disagree with the characterization that $select is an absolute requirement for every Web API project.

John Galt

2. Write a million methods for every permutation and combination of select query that your site or api request could want in the way of fields.

The majority of the things the users will want to do with a standard Web API will include sorting, paging, and filtering. These operations are all supported.

John Galt

(And quite honestly, I don't have a clue why anyone in MS would ever find it acceptable to release a product that is this brutally inefficient and encourages (REQUIRES!) such incredibly bad design that goes DIRECTLY AGAINST your own development guidelines: Only get the data you absolutely need only when you absolutely need it. Data access is the most expensive part of ANY programming. You can optimize your string commands and loops all day long, but a query to the database will ALWAYS cost more than essentially every other operation in programming. Thus to REQUIRE that the data fetch be inefficient to start, and then REQUIRE that all of that useless information be sent over the (low speed) wire is rediculous. And given that displaying lists of data is probably 80% of most applications with CRUD being the other 20% this is the FIRST case you should have optimized, not the last.)

I'm afraid that I don't understand the point you're making. Queryables create optimized queries already; they do not issue "select *" as you seem to imply they do. Can you provide network traces of cases where standard Entity Framework LINQ queries issue "select *"?

Re: Hacking $select into Web API

John Galt

Web API uses OData for most of it's responses. It's the core of the system. Yes you can do things like returning a pure string and even dynamic etc. but the power of the system lies in the ability to page, sort, and SELECT against your data source.

This statement is false. Web API supports the OData query syntax, in part, but it does not use OData. Any exposed IQueryable is an implementation detail. Can this be abused? Certainly. The same arguments you make here and elsewhere hold against MVC, as well.

John Galt

Any SPA or indeed anyone using WebAPI is going to need projections approximately 80% of the time given that the average project will display lists of data about 80% of the time and CRUD about 20% of the time (Microsoft's own numbers when describing the power of OData!).

This still relates to OData, not Web API. It seems you've become confused b/c of the acceptance of the OData query syntax. Web API is not OData. If you want to expose OData directly, you should be using WCF Data Services rather than Web API.

Web API is a tool for you to manage interactions across the HTTP protocol. OData is something else. The query syntax is supported as a convenience. Perhaps it would be more clear if that was an opt-in, perhaps only with full OData support that is yet-to-come. Would that clear things up more?

John Galt

Thus MS is making excuses for why they're not supporting the most important operation there is, second only to WHERE when using a database. And the result is going to be crappy, slow applications that don't scale -- Or people simply won't use it.

And yes, this is supposed to be the long term replacement for WCF OData Services (WCF Web API is it's official name and this is just ASP.NET Web API for a reason).

No, this is no longer part of WCF, nor is it a long-term replacement for WCF OData Services. Where did you get that? (Or perhaps I'm wrong? Brad? Marcin?) Web API doesn't support OData in the full, so it is in no way a replacement. That's a provably false assertion.

John Galt

Hence my frustration. I have to use the old, brutally complex WCF Web API for the new project I'm working on because MS won't get their replacement for WCF WEb API right until V3. Then when V3 comes along I'm going to have to completely retool the guts of our app and likely break our own client implementations AND third parties using our API because MS will have depreciated WCF Web API when they release Version 1 of ASP.NET Web API leaving it the bastard child that will lose functionality support in VS.net much like they did with WSE when they brought out WCF, even though WCF to this day still doesn't support major parts of WSE several versions later (Shared Secret with encrypted communication without having to have an expensive x509 certificate anyone?).

Same old MS routine. Did it with Linq to SQL, did it with WSE, did it with WinForms (same as VB 6 stuff and thus broken from day one) to WPF To Silverlight, etc. etc. etc: Good implementation of something but gets unwhiedy as versions go by because of the lack of forsight originally, ditch it for something new, but the something new isn't really done and doesn't really replace the old stuff, but support for the old stuff that actually worked, even if it was brutally complex goes away. Then we're left with busted stuff that we have to hack to work until MS finally fixes it and puts in all of the stuff they missed the first time, but then the cycle continues.

Wash rinse repeat.

I understand that things evolve over time and you need to adapt and new technologies come along. What I don't understand is MS's ability to accept major breaking issues and push them out the door anyhow because of some timeline. It's the core difference between Apple and Microsoft. SJ released products when he was good and ready and he liked the results and it worked as intended. Microsoft releases them for beancounters whether or not their ready and work in the scenarios that are clearly required. SJ added new features that were world changers, not new features that should have obviously been required for the previous version. (i.e. the addition of the app store to iOS back in the day)

Next stop the completely unfinished Windows 8 that breaks the usage of all power users of desktop computers because they are not going to actually address the core issue of replacing the start menu with something that's actually usable in this scenario. Tech geeks will get pissed off just like they did with Vista, adoption will be horrible on all things other than tablets and maybe laptops because the geeks will tell all of their friends that it sucks and to stay away and MS has another Vista on their hands. Windows 9 will address this glaring issue that a billion 3rd parties have hacked into the OS and made the OS flaky in the process and tech geeks will like it and it will get wider adoption... if MS hasn't outright lost by that point simply because they think they need to hit an arbitrary release date instead of making a really great product that really works for the scenarios it's designed for.

Apple is almost a trillion dollar company. Meanwhile Microsoft has 0 growth and 0 increase in stock price as a result since Bill Gates left. This is why and it's too bad.

This is just bad form. I can understand the frustration if your understanding and assertions were accurate, but they aren't. Where did you get the information that Web API was a replacement for WCF Data Services? I think that's the root of the problem. Don't use Web API. Use WCF Data Services. So far as I'm aware, that project is alive and well.

Re: Hacking $select into Web API

Now that I understand the $select notation, you could also create an HttpMessageHandler to control your ObjectContext and manipulate the returned data. Then in your Controller, you could just call the pre-defined query and return the value. At any rate, HttpMessageHandlers seem a good place for managing creation and disposal of dependencies. This may be a good way to implement full OData support in Web API.

Re: Hacking $select into Web API

panesofglass

No, this is no longer part of WCF, nor is it a long-term replacement for WCF OData Services. Where did you get that? (Or perhaps I'm wrong? Brad? Marcin?) Web API doesn't support OData in the full, so it is in no way a replacement. That's a provably false assertion.

You are correct. Web API does not support full OData (just a subset of the query syntax). It is not intended to be a replacement for WCF Data Services.

Re: Hacking $select into Web API

No more room for complaining anymore. Don't like that a feature is missing? Send a pull request. http://aspnetwebstack.codeplex.com/

Re: Hacking $select into Web API

The problem with this approach is that dynamic isn't returning odata and you lose filter and sort so now you have to implement those manually as well. (at least this is my understanding)

And if you use IQueryable as your return and only fill in certain parameters with $select you've got a mess of null properties that aren't really null.

And given that dynamic doesn't really work with upshot because it's not odata anymore, it all breaks.

It needs to return IQueryable<Contact> and select from there and return an array of classes that are dyanmically generated.

I'm all ears for solutions that actually work and don't create a mess.

And for those of you saying just use WCF Data Services, that's like telling the guy that just got hold of Entity Framework V1.0 that he can just use Linq to SQL while he knows full well that LInq to SQL is dead and never going to be improved ever again while Entity Framework will, so you're forcing him to use linq to sql to make it work now while MS spends 3 versions getting EF right so that you can finally use it, and then having to re-write your entire data access layer because it's 100% clear that you've dead-ended yourself.

Same here. WCF Data Services and WCF Web API are toast. ASP.NET Web API will be the only one left at the end of the day except for legacy. WCF will still be there for hard core stuff and might evolve, but even that's doubtful over time.

So because MS hasn't thought this out very well and thought about real deployable apps and especially LOB apps that SPA is going to target, we're left with two unworkable solutions to the problem.

Hence my frustration.

And a pull request.... ya that's the ticket! MS devs won't do it until they're good and ready (likely AFTER V2!) and if you put it in yourself you're left with having to merge it every time MS changes it, and when they finally do enable $select, your stuff is broken, it's just a matter of how bad. Yes, excellent solution.

Re: Hacking $select into Web API

John Galt

Same here. WCF Data Services and WCF Web API are toast. ASP.NET Web API will be the only one left at the end of the day except for legacy. WCF will still be there for hard core stuff and might evolve, but even that's doubtful over time.

So because MS hasn't thought this out very well and thought about real deployable apps and especially LOB apps that SPA is going to target, we're left with two unworkable solutions to the problem.

Hence my frustration.

Where are you getting that WCF Data Services is getting EOL'd? I've been talking with the Web API team over the last year and never heard anything about Web API being targeted as a replacement for WCF Data Services. That was true even as WCF Web API. Thus, I'm still totally confused. It sounds like you want OData, and that's available in WCF Data Services.

Perhaps you are requesting Microsoft abandon WCF for Web API wrt OData? If that's the case, you should state that as a request, not by pointing out that Web API is somehow broken.

Re: Hacking $select into Web API

And panesofglass:

Web API absolutely implements ODATA. All responses of type IQueryable<> are Odatable, except they forgot to implement $select. They fully support $sort and $filter.

So the delta between WCF Data Services and Web API is: $select. (and some minor other $commands that are rarely used).

Given this fact, can you seriously tell me that WCF Data Services isn't a dead duck? Especially considering that Silverlight just got killed by implication now that Windows 8 Phone has put silverlight as legacy for WinRT? The one platform where WCF Data Services was actually native and used and it's toast, meanwhile HTML + JQuery is now on par with C# and XAML in Win RT?

MS isn't going to continue deving WCF Data Services when Web API covers almost all of it and will eventually cover the entire thing and maintain 2 apis, especially when their pushing Web API for SPA and MVC.net which are in large part the basis for WinRT apps written in HTML.

They will absolutely dump all of the other alternatives and just use Web API and tell everyone XAML, HTML and other to use this in the backend and brag about the interoperability. It's a forgone conclusion. There may be lot of people even in MS that haven't figured this out yet just like the Linq to SQL people thought that their technology was going to live on, but anyone that has seen MS's past actions in this same situation knows what's coming. It's a matter of when not if.

And given that the when is < 3 years away (and by RTM of VS.net 2012 we'll be told, if not directly, just like they told us last spring that Silverlight and WPF were dead and only really admitted it in September) this has a massive impact on all new development of new projects that are being started today, because it means inband re-writting of the services layer of any new app at some point soon in those next 3 years or not being able to innovate with new features because you're stuck on the old, legacy supportted WCF Data Services. Been there with Linq to SQL, not doing it again.

I successfully predicted > a year ago that Silverlight was toast and that we shouldn't develop anything on Silverlight and should delay any new projects until MS told us what was going to replace it. I did the same with Linq to SQL, and nailed the Nokia partnership/take over perfectly, and looks like my assertion 2 years ago that MS was going to buy RIM is about to come true again unless the Canadian government gets in the way is also going to be true. Thus I'm really good at this and can read MS's writting on the wall. I'm also going to be proven correct about Windows Media Center too but that's another story...

Re: Hacking $select into Web API

John Galt

WCF Data Services and WCF Web API are toast. ASP.NET Web API will be the only one left at the end of the day except for legacy. WCF will still be there for hard core stuff and might evolve, but even that's doubtful over time.

This statement is false. WCF Data Services is not dead, is not EOL'd, is being worked on by the WCF team, and is our recommendation for people who want to implement OData endpoints.

Please stop spreading FUD (or wishes) as though they were fact.

Re: Hacking $select into Web API

John Galt

And panesofglass:

Web API absolutely implements ODATA. All responses of type IQueryable<> are Odatable, except they forgot to implement $select. They fully support $sort and $filter.

So the delta between WCF Data Services and Web API is: $select. (and some minor other $commands that are rarely used).

Given this fact, can you seriously tell me that WCF Data Services isn't a dead duck?

See Brad's response. If you believe what you express, then I think you should consider OData dead, as well. Nothing was forgotten. The query syntax was provided as a convenience. Web API cannot support OData in the full as it doesn't natively integrate with Entity Framework as WCF Data Services does. I wish more and more it had been left off entirely.

I can confidently say that Web API absolutely does not implement OData. All you see is the thin query syntax vaneer. OData is a much larger beast and is not implemented in Web API.

Re: Hacking $select into Web API

John,

Your attitude is offensive and completely uncalled for. Making the situation worse is that your understanding of the ways in which people build distributed systems is severely limited.

Some people, myself included, believe the idea of allowing client applications to manufacture a huge number of variants of a remote representations by allowing them to do projections is counter-productive because of the huge negative impact it has on caching.

If you are really serious about performance of a Web API then you would never consider exposing your database over HTTP using a form of generic querying language.

OData is the MS Access of the Web API world, you can get quite a way with it in a short amount of time, but I would never recommend it to build a core API unless, "reach in the MS world" is the primary requirement and performance is not so critical.

And as Dave said, if you don't like what MS are doing, fork it and fix it. But please drop the attitude.

Darrel

Re: Hacking $select into Web API

Return IQueryable<> from any Web API method.

It gives you OData and supports OData commands.

Go watch any of the SPA examples online. You'll see the same.

The only thing that isn't supported is $select. Why it's not supported I have no idea because adding it appears to be straight forward if I can cast to System.Net.Http.HttpResponseMessage<System.Linq.IQueryable> from the actionExecutedContext.Result.Content when I don't know the type of the IQueryable.

Once I have the object, I can use dynamic linq (just like filter and order are doing) to return a projection instead

Just need to know how to cast and I'm set and this should be added to Web API/SPA, however MS wants to parse who gives Web API the ability to do odata. (and note that WCF Web API clearly states on the project page on code plex that it supports odata just not $select and this is the same stuff with a different name and updates.

Re: Hacking $select into Web API

"This statement is false. WCF Data Services is not dead, is not EOL'd, is being worked on by the WCF team, and is our recommendation for people who want to implement OData endpoints.

Please stop spreading FUD (or wishes) as though they were fact."

That's exactly what the Linq to SQL people said when V1 of EF came out.

The Silverlight team said the same thing 3 months before WinRT was released and said the same thing with V5 of silverlight was released to only be proven completely wrong 2 weeks ago when even Windows Phone 8 people admitted that silverlight is now legacy and all apps should be recompiled to Win RT once Windows Phone 8 comes out. (And Windows 8 basically doesn't support Silverlight except in legacy mode)

Fortunately I've learned how to read the contradictory messages from within Microsoft and know how to see the writting on the wall. I might be wrong this time, but I doubt it. It's more likely that the WCF team, just like the Linq to SQL and Silverlight teams before it hasn't gotten the message yet. It might take until V2 of Web API for that to occur but I'd be willing to put $US 100 on it that by V3 of ASP.NET Web API RIA Services in WCF is EOLed and in support mode only.

Re: Hacking $select into Web API

"Your attitude is offensive and completely uncalled for. Making the situation worse is that your understanding of the ways in which people build distributed systems is severely limited."

I support 10 million simultatious users with response times of < 1 second for every page in mission critical insurance scenarios for a living.

I handle the accounting for 4000 businesses including fortune 500s.

My software runs a bank that handles a million transactions + a day. (and growing at 20% per quarter)

So please don't be condesending and suggest that I don't know what I'm doing.

"Some people, myself included, believe the idea of allowing client applications to manufacture a huge number of variants of a remote representations by allowing them to do projections is counter-productive because of the huge negative impact it has on caching. "

If you're going to relying on caching to protect you from returning Select * to the N, then I strongly suggest that you find another job. Caching is a small part of the process. Returning the least data possible and querying as rarely as possible is the first step, caching is just a way of aliviating duplicate requests. If you're doing client side pretty presentation sites like ecommerce you might get away with just caching values because the limited set of data would allow it.

But if you're writting line of business applications forget it. The data set is too variable to make up for the wasted data hit on the server. And SPA is all about Line of Business (and similar apps). It cannot be effectively used in ecommerce or other Search Engine facing sites because it's dyanmic and cannot be indexed.

"If you are really serious about performance of a Web API then you would never consider exposing your database over HTTP using a form of generic querying language."

Step #1: Filter data for security based on user and system rules.

Step #2: Filter data for the request based on user requested information

Step #3: Throttle uncontrolled requests to ensure 10 billion records cannot be returned.

Step #4: Return the latest amount of the total result set as possible and request from the Database server the least amount of data possible by filtering out columns that are not required.

Step #5: Display data to end user.

When using web services of any kind you MUST do every one of these steps.

If using SOAP you do this by using many methods and return limited classes or other methods (i.e. return json inside the soap response) because you don't have any other choice.

Using OData doesn't make your data consumation any worse. In fact if implemeted properly it makes it significantly better because instead of having to write a response class per endpoint that specifies the fields (which won't happen, devs will just return all of the fields possibly needed and let the client sort it out) the client can request only the fields it needs. The WORST case scenario is the best case scenario for Web API as it stands now and the likeliest scenario for WCF SOAP or similar.

"OData is the MS Access of the Web API world, you can get quite a way with it in a short amount of time, but I would never recommend it to build a core API unless, "reach in the MS world" is the primary requirement and performance is not so critical."

I strongly suggest you rethink that assertion as it's just completely and utterly wrong. Yes, if you don't know what you're doing, you can encur the same penalty as what you get out of the box with WCF returning EF disconnected classes, or RIA Services without a select. But that's your worst case scenario. Your best case scenario is MUCH MUCH BETTER.

And if you control access to said services and have setup your security correctly MUCH MUCH BETTER is so much better and so much less overhead to be embarassing.

"And as Dave said, if you don't like what MS are doing, fork it and fix it. But please drop the attitude."

I am. But my point still stands. MS is failing to think about use scenarios here and going to result in a very limited use set for what they've so far provided and thus the standard MS V1 barriers to use.

Re: Hacking $select into Web API

This is not the first time someone complaint about $select. If someone needs a complete implementation of oData he can use Wcf Data services...I found the actual implementation of the oData protocol very usefull in business application. A FULL implementation of oData protocol is dangerous because it gives too much power to the client with no control on the server. If you need to perform complex operations on your IQueryable please move them to the server, there you are sure none can change them. Queries stored in the html page can be changed by a malicious user.

In my opinion a restricted implementation of oData protocol open WebApi the possibility to expose big databases on the web without too much risk and help building business applications more easily. On the contrary a full implementation of the oData protocol can be used only on small databases such ase news feeds that perform accettably also if the client submit "dangerous" queries....

I am already using webapi and I NEVER needed to use a $select! I DECIDE ON THE SERVER SIDE wich properties to expose adding the select I need BEFORE expsosing the IQueryable on the web. Do you realy want a malicious use change you query to see property you DON'T WANT TO expose? Obviously NOT...so FOR SURE you have to apply a select before exposing your IQueryable on the Web...