MVC has Areas to support the creation of different components but the Odata implementation does not support this. Specifically I would like to be able to use OData Controllers with the same names as other Web API or MVC controllers.

I'd like to see a complementary OData client to go along with ASP.NET Web API OData services.

The current, built-in "WCF Data Service References" in Visual Studio are very "heavy" in nature and don't fit the more modern style of entity programming very well.

In particular, it doesn't support sharing a common set of "code first" entities. The biggest problem is that OData doesn't natively support enumerations, so they end up being converted to "Int" or "String" in the OData data model. A shared entity model would help this problem somewhat, and allow for code reuse.

I think maintaining and working with ASP.NET MVC and ASP.NET Web API side by side in the same project is a drain on development resources and support cost.
I would like to use ASP.NET Web API to generate Razor views via an additional NuGet package rather then relying on ASP.NET MVC.

I would really like it if the CREF tag was honored in the WebAPI documentation pages. Example:

<param name="resizeType">The resize type as defined in <see cref="MyModels.ResizeTypeEnum"/></param>

Should dynamically pull information from the summary found at MyModels.ResizeTypeEnum and put it in the Help Page

One of the primary ideas behind a REST API is that it is stateless. The current implementation of Web API seems to rely on Form Based Authentication. I would suggest ripping API Authentication out by default and have the default Web API template modified to reflect that. A selection of authentication of providers should be provided by the community or separate plug and play solutions.

The current Web Api Client is not compatible with Mono For Android, and trying to use HttpWebRequest and OData from Android mobile app. is a pain. Not sure about the amount of effort involved, but the author of Json.Net recently provided an mfa-compatible version, packaged as a Portable Class Library.

Add an optional parameter to the HttpMethodAttributes to enforce SSL on methods/actions eg.

[HttpGet(SSL=Required)]
public .... Get(){}

[HttpPost(SSL=Optional)]
...

[HttpPut(SSL=NotSupported)]
...

Right now Web API is viewed as a component under AP.NET MVC. But, in my opinion, it should be available as just a common file template. The file template is available now, but still developers categorize Web API under ASP.NET MVC. Please evangelize Web API such that it will be viewed as a component under ASP.NET core.

It is just my opinion. You may correct me if I am wrong.

When using REST services in smart clients or rich JavaScript clients, it is normal to cache changes on the client side and send multiple updates back as a batch. Being able to leverage the change sets support in OData for this would be great.

I think most people expectations would rightfully (IMHO) that WebAPI would support everything MVC does minus any view rendering or ActionResult overhead. When I search the web I see many comments relating to "I can do X in MVC but not in WebAPI". Example: Multipart/form-data or jsonp handling works in MVC out of the box.

Original discussion here: http://aspnetwebstack.codeplex.com/workitem/184

This is a serious limitation to patching.

http://aspnetwebstack.codeplex.com/workitem/562

http://aspnetwebstack.codeplex.com/workitem/386

There is no way to forecast the execution order of WebApi Action Filters. It changes randomly each time the code is changed. It would be nice to have an integer property to control the order like in normal Mvc controllers, but also respecting the order they are put on the action method would be acceptable

I *love* Web API, but this is inexcusable:
http://msdn.microsoft.com/en-us/library/hh833994.aspx

Currently the XML serialisers both output namespaces that are not required:

xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";

I'm not sure about the Data Contract serializer, but it is not difficult to supress these...

Just pass into the Serialize method an XmlSerializerNamespaces:

var xmlSerializerNamespaces = new XmlSerializerNamespaces();
xmlSerializerNamespaces.Add(String.Empty, defaultNamespace);

var xmlSerializer = new XmlSerializer(objectType);
xmlSerializer.Serialize(xmlWriter, toBeSerialised, xmlSerializerNamespaces);

Where defaultNamespace could be set on the GlobalConfiguration.Configuration.Formatters.XmlFormatter or it could be read from the XmlRoot attribute (if present) on the object being serialised.

Integerated OAuth Authentication for Asp.net WebApi including OAuth Service Provider.