odata/webapi

OData Web API: A server library built upon ODataLib and WebApi

OData Web API

Build	Status
Odata.WebApi Rolling Dotnet pipeline
WebApi Rolling
WebApi Nightly

Introduction

OData Web API (i.e., ASP.NET Web API OData) is a server library built upon ODataLib and Web API.

Project structure

The project currently has the following branches:

master branch

This is the active development branch for OData WebApi and it is currently most actively iterated. The package name is Microsoft.AspNet.OData. The is the OData WebApi for ODL v7.x releases which contain breaking changes against ODL v6.

release branch

This is the release branch for OData WebApi, contains code base up to most recently stable WebApi release. The latest release version is 6.0.

feature/netcore branch

This is the feature development branch for OData WebApi for AspNet and AspNetCore. The package names are Microsoft.AspNet.OData and Microsoft.AspNetCore.OData. The is the OData WebApi 7.0 release which contain breaking changes against OData WebApi 6.0.

gh-pages branch

The gh-pages branch contains the old documentation source for OData WebApi - tutorials, guides, etc. For the most up-to-date documentation you should use Microsoft docs.

maintenance-aspnetcore branch

This is the maintenance branch for OData WebApi with ASP.NET Core support. The package name is Microsoft.AspNetCore.OData.

maintenance-V4 branch

This is the maintenance branch for OData WebApi based on ODL 6.x, which implements the ODataV4 protocol. The package name is Microsoft.AspNet.OData, with latest maintenance release version 5.10.

maintenance-V3 branch

This is the maintenance branch for OData WebApi based on ODL 5.x, which implements the ODataV3 protocol. The package name is Microsoft.AspNet.WebApi.OData, with latest maintenance release version 5.7.

maintenance-dnx branch

This is maintenance branch for an early prototype version of OData WebApi based on original ASP.NET Core, aka DNX. Package name is Microsoft.AspNet.OData. This is for project archive purpose only, is not active and doesn't accept contributions. It has only one release.

odata-v5.3-rtm v2.0-rtm v3-rtm v3.1-rtm v3.2-rtm branches

These are maintenance branches for previous RTMs. Project archives only, contributions not accepted.

Building

build.cmd

Testing

Each solution contains some test projects. Test projects use xUnit runner nuget package.

Tests will not run correctly unless SkipStrongNames is Enabled. Please run

build.cmd EnableSkipStrongNames

Run tests in cmd

To run end-to-end tests, you need to open an elevated - Run as administrator - command prompt

• build.cmd build projects, run unit tests, and OData end-to-end tests.

• build.cmd quick build project, and run unit tests

To disable the SkipStrongNames:

build.cmd DisableSkipStrongNames

Run tests in Visual Studio

Open the project, build it, and then test cases should appear in test explorer. If not, this is because the assemblies are delay signed and you're missing the private key so xunit will not load them in Visual Studio. To fix, please run build.cmd EnableSkipStrongNames. Run all the tests in the test explorer. For running end-to-end tests you must open the solution as Administrator. More detail at this.

Nightly builds

The nightly build process will upload a NuGet packages for WebApi to: v7.x.x: MyGet.org webapinetcore feed v6.x.x: MyGet.org webapinightly feed

To connect to webapinightly feed, use this feed URL: v7.x.x: webapinetcore MyGet feed URL v6.x.x: webapinightly MyGet feed URL

You can query the latest nightly NuGet packages using this query: v7.x.x: MAGIC WebApi query v6.x.x: MAGIC WebApi query

Contribution

Please refer to the CONTRIBUTION.md.

Reporting Security Issues

Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) [email protected]. You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the Security TechCenter. You can also find these instructions in this repo's SECURITY.md.

Documentation

Please visit the OData Web API pages.

Samples

Please refer to the ODataSamples Repro.

• ASP.NET Core OData samples at here
• ASP.NET Classic OData samples at here

Debug

Please refer to the How to debug.

Code of Conduct

This project has adopted the .NET Foundation Contributor Covenant Code of Conduct. For more information see the Code of Conduct FAQ.

.NET Foundation

This project is supported by the .NET Foundation.

WebApi is a Copyright of © .NET Foundation and other contributors. It is licensed under MIT License

webapi's Issues

Consistent handling of Null Values

According to OData V4 spec, requesting an entity that doesn't exist (i.e.,
~Customers('key-that-does-not-exist') should return 404 (we do this today) but
requesting a single-valued (non-collection) entity, property, nav property, or
function result should return 204 (no content) if the value is null. In V3 I
believe we return null values for properties and function results.

e.g., now in webapi.odata, we have handle logic for raw value as a reference:

if (IsRawValueRequest(request) && response.IsSuccessStatusCode)
{
ObjectContent content = response.Content as ObjectContent;
if (content != null && content.Value == null)
{
actionExecutedContext.Response = request.CreateResponse(HttpStatusCode.NotFound);
}
}

Work Item Details

Original CodePlex Issue: Issue 1602
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jan 6, 2014 at 7:24 AM
Reported by: cysu
Updated on: Jan 6, 2014 at 7:24 AM
Updated by: cysu

Provide api to make Action parameters Nullable

For the following action, I would like to make the parameter 'p3' nullable.
Currently, there is no api on the ActionConfiguration which can make it
Optional or Nullable.

var actionConfig = vehicle.Action("TestAction1");
actionConfig.Parameter("p1");
actionConfig.Parameter("p2");
actionConfig.Parameter("p3");

Also, from the schema, there seem to be other attributes like "MaxLength",
"Precision", "Scale" etc. that can be provided for FunctionImport's
parameters:

<xs:attributeGroup name="TFunctionImportParameterAttributes">

<xs:attribute name="Name" type="edm:TSimpleIdentifier" use="required" />
<xs:attribute name="Type" type="edm:TFunctionImportParameterAndReturnType" use="required" />
<xs:attribute name="Mode" type="edm:TParameterMode" use="optional" />
<xs:attribute name="Nullable" type="xs:boolean" use="optional" />
<xs:attribute name="MaxLength" type="edm:TMaxLengthFacet" use="optional" />
<xs:attribute name="Precision" type="edm:TPrecisionFacet" use="optional" />
<xs:attribute name="Scale" type="edm:TScaleFacet" use="optional" />
<xs:attribute name="SRID" type="edm:TSridFacet" use="optional" />
<xs:anyAttribute namespace="##other" processContents="lax" />

/xs:attributeGroup

Work Item Details

Original CodePlex Issue: Issue 461
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Sep 26, 2012 at 3:19 AM
Reported by: kichalla
Updated on: Sep 23, 2013 at 7:15 PM
Updated by: danroth27

Add containment support to the OData model builder

We expose all the entity sets at the root level in the service document. we
should support containment scenarios.
As an example, entity set 'orders' is contained by the entity set 'customers'.
One cannot address an order without getting to the customer who owns that
order.

Work Item Details

Original CodePlex Issue: Issue 566
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Oct 19, 2012 at 3:49 AM
Reported by: raghuramn
Updated on: Feb 4, 2014 at 8:11 PM
Updated by: thebothead

add model validation pass in odata model builder

we should validate things like when users build edm models explicitly (not for
the implicit model we build in query composition)

1. an entity type has key(s).
2. an entity type has a corresponding entity set.
3. all navigation properties are bound to an entity set.
4. a non-abstract entity type is bound to a non-abstract clr type.
5. all properties in an edm type have public setters and public getters in the
   backing clr type.

Work Item Details

Original CodePlex Issue: Issue 437
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Sep 20, 2012 at 7:34 PM
Reported by: raghuramn
Updated on: Oct 3, 2013 at 11:49 PM
Updated by: danroth27

V5.5: Support of Abstract EntityTypes without any keys

Currently, Web API doesn't allow abstract entity type without key.

However, OData V4 spec says:
An abstract entity type MAY define a key if it doesn’t inherit one.

So, please work to support abstract entity type without any keys:

Support insert and bind of entities via links

Example:
In ODataService sample, Product entity type has a required relationship with
ProductFamily. Product cannot exist without a Product Family.

Currently we can submit a Product without any existing relationship with a
ProductFamily. I believe we should throw some kind of validation error.
According to insert and bind' we could supply the rel links to which you would
want to associate the to-be-created entity instance. Since this scenario is
fairly common, we should support it.

Following is an example from the OData PDF spec:

2.2.7.1.1.1 Examples

Example 1: Insert a new Customer and bind it to existing Orders with key
values 1 and 2 by using the Atom format.

HTTP Request:

POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml
Accept: application/atom+xml
Content-Length: nnn

http://host/service.svc/Customers('ASDFG')</id
>

<title type="text" /> 2008-12-07T8:00:00Z

<name />

<m:properties>
  <d:CustomerID>ASDFG</d:CustomerID>
  <d:CompanyName>Contoso Widgets</d:CompanyName>
  <d:Address>
    <d:Street>58 Contoso St</d:Street>
    <d:City>Seattle</d:City>
  </d:Address>
</m:properties>

## Work Item Details

Original CodePlex Issue: Issue 528
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Oct 9, 2012 at 8:00 PM
Reported by: kichalla
Updated on: Oct 3, 2013 at 11:46 PM
Updated by: danroth27

Investigate to support DateTime in WebApi, OData lib v4 will not support it.

OData lib v4 will not support DateTime. But for customer, the DateTime is used
frequently. So, please investigate whether and how to support DateTime in
WebApi.

Work Item Details

Original CodePlex Issue: Issue 1559
Status: Proposed
Reason Closed: Unassigned
Assigned to: xuzhg
Reported on: Dec 17, 2013 at 6:04 AM
Reported by: xuzhg
Updated on: Dec 17, 2013 at 6:04 AM
Updated by: xuzhg

Creating links to other OData routes is hard

I have to figure out the appropriate path handler to use. The framework
already knows which path handler should be used when I provide a route name;
it shouldn't ask me for it.

Possible scenarios:
I want to create an OData link from an ODataController associated with a
different model. In particular, I might be versioning and want to create a
link from one version (v2) to another (v1).
I want to create an OData link from an ApiController (non-OData). In
particular, I might want to migrate to OData and this method would give me an
entry point to the OData world from the non-OData world.

Work Item Details

Original CodePlex Issue: Issue 771
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jan 14, 2013 at 8:02 PM
Reported by: davidmatson
Updated on: Sep 23, 2013 at 7:43 PM
Updated by: danroth27

Add support for generating odata urls from razor views.

Context from this SO question,
[ http://stackoverflow.com/questions/15488574/how-to-link-to-odata-collection-
in-razor-using-asp-net-mvc-web-api-odata
](http://stackoverflow.com/questions/15488574/how-to-link-to-odata-collection-
in-razor-using-asp-net-mvc-web-api-odata)

Work Item Details

Original CodePlex Issue: Issue 914
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Mar 19, 2013 at 3:26 AM
Reported by: raghuramn
Updated on: Jun 11, 2014 at 11:10 PM
Updated by: bplumlee_rtc

[TestInport] MVC Editor Templates should support HTML5 input types such as tel, url, and email when [DataType] is applied to the property

For example, imagine this model type:
public class MyModel
{

public int ID { get; set; }

[DataType(DataType.Url)]
public string WebSite { get; set; }

[DataType(DataType.EmailAddress)]
public string Email { get; set; }

}

In MVC3 it gets rendered roughly like this (with everything set to
type="text):
ID:
WebSite: <input type=”text” name=”WebSite” value=”
http://example.com/path/file.html” />
Email: <input type=”text” name=”Email” value=”[email protected]”
/>

In MVC4 it should render more appropriate "type" attributes:
ID:
WebSite: <input type=”url” name=”WebSite” value=”
http://example.com/path/file.html” />
Email: <input type=”email” name=”Email” value=”[email protected]”
/>

We need to do this automatically for tel, url, email, datetime, date, time,
and number.

Work Item Details

Original CodePlex Issue: Issue 2
Status: Closed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Mar 25, 2012 at 11:47 PM
Reported by: eilonlipton
Updated on: Jan 24, 2014 at 6:38 PM
Updated by: davidmatson
Closed on: Jun 23, 2012 at 12:56 AM
Closed by: bhaveshc

Add AllowedFilterProperties to the Queryable attribute

Similar to AllowedOrderByProperties.

Work Item Details

Original CodePlex Issue: Issue 851
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Feb 15, 2013 at 11:54 PM
Reported by: bbache
Updated on: Sep 23, 2013 at 7:29 PM
Updated by: danroth27

Provide a default implementation for changeset unit of work semantics in OData $batch

The current implementation of DefaultODataBatchHandler doesn't provide any
kind of Unit Of Work semantics as defined for changesets in the OData V3
specification. The current implementation processes the changeset but doesn't
perform any kind of rollback operation in case of failure, which is the wrong
default behavior.

Provide an abstract method that the user needs to implement in order to
provide rollback semantics to be able to use an ODataBatchHandler and provide
a default implementation in the DefaultODataBatchHandler that handles the
majority of the use cases.

The excerpt from the ODataspec:

"All operations in a ChangeSet represent a single change unit so a service
MUST successfully process and apply all the requests in the ChangeSet or else
apply none of them. It is up to the service implementation to define rollback
semantics to undo any requests within a ChangeSet that may have been applied
before another request in that same ChangeSet failed and thereby honor this
all-or-nothing requirement"

Work Item Details

Original CodePlex Issue: Issue 1096
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jun 19, 2013 at 11:47 PM
Reported by: jacalvar
Updated on: Sep 23, 2014 at 11:09 PM
Updated by: adamstoffel

Consider automated server paging based on ResultLimit with next page links that use $skiptoken instead of $skip

Next page links right now:

[ http://localhost/Customers?$skip=10 Skiptoken is more performant and robust
](http://localhost/Customers?$skip=10

Skiptoken is more performant and robust) .

Work Item Details

Original CodePlex Issue: Issue 500
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Oct 3, 2012 at 11:54 PM
Reported by: youssefm
Updated on: Nov 24, 2014 at 11:54 PM
Updated by: goldenfire6

Can't unit test code that generates OData links

There's no unit that encapsulates the logic around generating a full OData
link, so tests end up integration style. Having an odata link factory
abstraction allows unit testing such code.

We are putting two related properties together on the request: path handler
and route name. These are a pair, which is a code smell that there's one
abstraction here that should be used instead. Having an odata link factor also
solves this problem.

Work Item Details

Original CodePlex Issue: Issue 769
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jan 12, 2013 at 1:50 AM
Reported by: davidmatson
Updated on: Sep 23, 2013 at 7:45 PM
Updated by: danroth27

ODATA v4 - Modifying Model to have custom metadata namespace prefix defect

I followed this example:

adding-arbitrary-data-to-odata-metadata-in-webapi

I had the exact same case. Basically the namespace prefix mapping to a
namespace does not work.
Instead of using a prefix the $metatdata returns with an autogenerated prefix
like "p5". As I add namespaces the numeric portion increases, but, never does
my mapped prefix get used.

Work Item Details

Original CodePlex Issue: Issue 2167
Status: Proposed
Reason Closed: Unassigned
Assigned to: lianw
Reported on: Oct 24, 2014 at 12:57 AM
Reported by: williamwsmith
Updated on: Tue at 8:56 AM
Updated by: cysu

Automatically discover ODataControllers and add them to the model

If the user derives from EntitySetController then they shouldn't need to
explicitly specify these entity sets in the model - we should just discover
them like we would for Web API and MVC controllers.

Work Item Details

Original CodePlex Issue: Issue 657
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Dec 1, 2012 at 12:26 AM
Reported by: danroth27
Updated on: Sep 23, 2013 at 7:23 PM
Updated by: danroth27

Add support for documentation to ODataConventionModelBuilder

This can be done easily by looking for the System.ComponentModel.Description
attribute on entities and properties, and using the EDM model's
SetDocumentation() method.

Work Item Details

Original CodePlex Issue: Issue 784
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jan 18, 2013 at 9:44 AM
Reported by: thargy
Updated on: Feb 7, 2014 at 7:01 PM
Updated by: troydalldorf

QueryableAttribute doesn't support query on public field

To repro:

public class Movie
{
public string Name = null;
}

public class MoviesController : ApiController
{
[Queryable]
public IEnumerable Get()
{

return new Movie[] {
  new Movie {
    Name = "Test"
  }
}

}
}

Send request: [ http://localhost/api/Movies?filter=Name eq null Response:
HTTP/1.1 ](http://localhost/api/Movies?filter=Name eq null

Response:

HTTP/1.1) 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?YzpcdXNlcnNcaG9uZ3llc1xkb2N1bWVudHNcdmlzdWFsIHN0dWRpb
yAyMDEyXFByb2plY3RzXE12Y0FwcGxpY2F0aW9uMlxNdmNBcHBsaWNhdGlvbjJcYXBpXE1vdmllcw=
=?=
X-Powered-By: ASP.NET
Date: Fri, 21 Sep 2012 18:30:50 GMT
Content-Length: 2070

{"$id":"1","Message":"The query specified in the URI is not
valid.","ExceptionMessage":"Type 'MvcApplication2.Models.Movie' does not have
a property
'Field'.","ExceptionType":"Microsoft.Data.OData.ODataException","StackTrace":"
at Microsoft.Data.OData.Query.MetadataBinder.BindPropertyAccess(PropertyAccess
QueryToken propertyAccessToken)\r\n at
Microsoft.Data.OData.Query.MetadataBinder.Bind(QueryToken token)\r\n at Micros
oft.Data.OData.Query.MetadataBinder.BindBinaryOperator(BinaryOperatorQueryToke
n binaryOperatorToken)\r\n at
Microsoft.Data.OData.Query.MetadataBinder.Bind(QueryToken token)\r\n at
Microsoft.Data.OData.Query.MetadataBinder.ProcessFilter(QueryNode query,
QueryToken filter)\r\n at
Microsoft.Data.OData.Query.MetadataBinder.BindTree(SyntacticTree syntax)\r\n
at Microsoft.Data.OData.Query.MetadataBinder.BindQuery(SyntacticTree
syntax)\r\n at Microsoft.Data.OData.Query.SemanticTree.ParseUri(Uri queryUri,
Uri serviceBaseUri, IEdmModel model, Int32 maxDepth)\r\n at
Microsoft.Data.OData.Query.SemanticTree.ParseUri(Uri queryUri, Uri
serviceBaseUri, IEdmModel model)\r\n at
System.Web.Http.OData.Query.FilterQueryOption.get_QueryNode() in C:\dd\DevDiv
Offcycle\WPT\WebStackRuntime\runtime\src\System.Web.Http.OData\OData\Query\Fil
terQueryOption.cs:line 68\r\n at
System.Web.Http.OData.Query.FilterQueryOption.ApplyTo(IQueryable query,
ODataQuerySettings querySettings, IAssembliesResolver assembliesResolver) in C
:\dd\DevDiv\Offcycle\WPT\WebStackRuntime\runtime\src\System.Web.Http.OData\ODa
ta\Query\FilterQueryOption.cs:line 123\r\n at
System.Web.Http.OData.Query.ODataQueryOptions.ApplyTo(IQueryable query,
ODataQuerySettings querySettings) in C:\dd\DevDiv\Offcycle\WPT\WebStackRuntime
\runtime\src\System.Web.Http.OData\OData\Query\ODataQueryOptions.cs:line
185\r\n at
System.Web.Http.QueryableAttribute.OnActionExecuted(HttpActionExecutedContext
actionExecutedContext) in C:\dd\DevDiv\Offcycle\WPT\WebStackRuntime\runtime\sr
c\System.Web.Http.OData\QueryableAttribute.cs:line 173"}

Work Item Details

Original CodePlex Issue: Issue 441
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Sep 21, 2012 at 7:36 PM
Reported by: hongyes
Updated on: Sep 19, 2013 at 11:35 PM
Updated by: danroth27

Add a simple hook to re-write all outgoing OData links.

Right now, we generate a bunch of links in the OData response payloads. These
are,

1. Self links - ID, edit and read links.
2. Navigation links,
3. Metadata links.

Customers want to use ODataConventionModelBuilder and yet have a simple way to
rebase the links that get generated. Doing it right now involves fixing up
these links for each and every entity set and navigation property which is lot
of code. Also, the metadata link cannot be changed.

WCF DS supports this scenario. Refer to this blog [ post
](http://blogs.msdn.com/b/peter_qian/archive/2010/03/24/overwriting-the-
service-root-uri-in-wcf-data-service.aspx) .

Work Item Details

Original CodePlex Issue: Issue 1247
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Aug 26, 2013 at 6:51 PM
Reported by: raghuramn
Updated on: Jan 27, 2014 at 6:10 AM
Updated by: zjufish

[OData] Add support for including non-key properties as well in the SelectExpand expression

We include the properties that the client has asked for (thorugh $select and
$expand) and the entity keys in the projection expression we generate in the
SelectExpandBinder.

If people customize their OData link generation, they might need to access to
other properties as well. For example, lets say a Person entity has Id (key)
and a Name, and, the generated links contain Name instead of Id.

We should add a setting on ODataQuerySettings to let people choose extra
properties that they want to bring from their database.

Work Item Details

Original CodePlex Issue: Issue 1017
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Apr 28, 2013 at 9:11 AM
Reported by: raghuramn
Updated on: Sep 23, 2013 at 7:32 PM
Updated by: danroth27

Emit navigation properties with source multiplicity '*' if the target multiplicity is one.

we emit properties with source multiplicity '0..1' by default if the target
multiplicity is 1. users cannot configure the source end of the multiplicity.
So, we should emit a better default which in this case is '*'.

Work Item Details

Original CodePlex Issue: Issue 792
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jan 18, 2013 at 10:20 PM
Reported by: raghuramn
Updated on: Feb 11, 2014 at 2:04 AM
Updated by: zjufish

Add support in the ODataPathParser for case insensitive comparisons

May be nice-to-have

Work Item Details

Original CodePlex Issue: Issue 619
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Nov 10, 2012 at 12:24 AM
Reported by: youssefm
Updated on: Sep 23, 2013 at 7:46 PM
Updated by: danroth27

Support ODataMediaTypeFormatter usage by HttpClient

My company expects to implement IIS hosted Web APIs that run on app servers.
These will be called by IIS hosted web applications that run on web servers.

We can therefore use ApiControllers on the app servers and call them from
HttpClient from the web servers. I like this programming model, where we use
the same MediaTypeFormatter and extensibility points at both ends of the wire.

We expect to use EntitySetController endpoints wherever we can, for general
CRUD operations, using the JSON light format. Then fall back to ApiControllers
if we have to - for operations like IN queries that OData doesn't support.

Ideally I'd like to be able to the following. These may need to use different
wire formats (maybe JSON.Net and JSON light). However, I don't want to have to
use a DataServiceContext to call EntitySetController, since supporting two
entirely different client side programming models adds a lot of work.

• Use the HttpClient to talk to an ApiController
• Use the HttpClient to talk to an EntitySetController

I think I'm right in saying that the second case requires the client to use
the ODataMediaTypeFormatter, and the client needs to provide an IEdmModel via
the HttpRequestMessage.SetEdmModel method. However, I've been unable to get
this to work, with various formatter / serialization problems.

If this supported currently, and if so can anyone point me to some sample
code? Any help appreciated.

Work Item Details

Original CodePlex Issue: Issue 1140
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jul 17, 2013 at 1:14 PM
Reported by: GaryArcher
Updated on: Feb 20, 2014 at 3:18 AM
Updated by: Seawerst

OData - Enable querying of untyped objects

Is it possible to add functionality to enable querying of untyped objects e.g.
dictionaries?

Code

[Queryable]
public List<Dictionary<string, object>> Get()
{
    var testSource = new List<Dictionary<string, object>>();
    for (var i = 0; i < 3; i++)
    {
        var e = new Dictionary<string, object>();
        e["Id"] = i;
        e["Notes"] = "Lorem Ipsum " + i;
        e["Date"] = new DateTime(1988 + i, 02, 02);

        testSource.Add(e);
    }

    return testSource;
}

Output

[
  {
    "Id": 0,
    "Notes": "Lorem Ipsum 0",
    "Date": "1988-02-02T00:00:00Z"
  },
  {
    "Id": 1,
    "Notes": "Lorem Ipsum 1",
    "Date": "1989-02-02T00:00:00Z"
  },
  {
    "Id": 2,
    "Notes": "Lorem Ipsum 2",
    "Date": "1990-02-02T00:00:00Z"
  }
]

How hard would it be to implement querying for following scenario? It would be
awesome for querying key/value stores that are taken from database and you
have no knowing beforehand what keys and values you have. Right now there is
no option to query these types of objects/dictionaries.

Work Item Details

Original CodePlex Issue: Issue 1310
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Sep 20, 2013 at 6:42 PM
Reported by: StanislavRomanov
Updated on: Nov 5, 2013 at 1:36 PM
Updated by: stefjnl

Add support for Spatial Data types in OData

Currently, there is no support for spatial data types in Web API OData.
Consider adding support for this as it makes impossible to develop any service
that has to deal with spatial data.

Work Item Details

Original CodePlex Issue: Issue 1010
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Apr 25, 2013 at 10:00 PM
Reported by: jacalvar
Updated on: Nov 24, 2014 at 10:41 AM
Updated by: jyparask

Please add support for entity key that are composed

Currently in order to support composite entity key we have to add new routing
conventions to ODATA web api server.

Since entity key may be composite according to ODATA spec it shall be a
feature ODATA web api supports out-of-the box.

Work Item Details

Original CodePlex Issue: Issue 898
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Mar 11, 2013 at 3:26 PM
Reported by: h28669
Updated on: Sep 15, 2014 at 7:40 PM
Updated by: mattvan

[OData] Add support for nested paging.

Now that we have $expand support, we should add support for server-driven
paging for expanded feeds.

Work Item Details

Original CodePlex Issue: Issue 1016
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Apr 28, 2013 at 9:06 AM
Reported by: raghuramn
Updated on: Dec 3, 2014 at 4:05 AM
Updated by: jorgeaguirre1

Expose ability convert FilterClause to Linq Expression

We can parse a filter to a FilterClause but there is no easy way to convert
that FilterClause to an Expression;

ex: var filterClause =
Microsoft.Data.OData.Query.ODataUriParser.ParseFilter(filter, model,
entityType);

it would be nice if we can then call filterClause.ToLinqExpression();

Work Item Details

Original CodePlex Issue: Issue 950
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Mar 30, 2013 at 2:33 AM
Reported by: a7medkamel
Updated on: Aug 4, 2014 at 11:29 PM
Updated by: britishbeans

Parsing the generated KeyValue in the KeyValuePathSegment should be done lazily

We are parsing the generated key-value in the KeyValuePathSegment. This should
be done lazily for performance

Work Item Details

Original CodePlex Issue: Issue 1459
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Nov 26, 2013 at 12:19 AM
Reported by: jacalvar
Updated on: Jan 27, 2014 at 6:09 AM
Updated by: zjufish

IEdmModel with entities inside value objects

I have an EDM Model where a Money object has a structure roughly as follows -
this is quite a common domain modeling example I believe:

public class Money
{
public Currency Currency {get; set;}
public decimal Amount {get; set;}
}

Money is a value object whereas Currency is an entity with a database id.
However, if I define my model as follows then my odata route is invalid.

var builder = new ODataConventionModelBuilder();
builder.EntitySet("Currencies");
builder.ComplexType();

I get the following error:

The complex type 'Dealogic.DemoService.Model.Money' refers to the entity type
'Dealogic.DemoService.Model.Currency' through the property 'Currency'.

There are a couple of possible workarounds:

• Give the Money value object just a currency id (not ideal because money calculations need to work with currency fields)
• Give the Money value object a DummyId field and add it as an entity, as below (a hack that will lead to further problems)

EntityTypeConfiguration money = builder.AddEntity(typeof(Money));
money.AddProperty(entityType.GetProperty("DummyId"));
money.HasKey(entityType.GetProperty("DummyId"));

I just wondered if anyone else has run into this problem and how they have
dealt with it? Will entities inside value objects be supported in the official
release?

Work Item Details

Original CodePlex Issue: Issue 1141
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jul 17, 2013 at 1:30 PM
Reported by: GaryArcher
Updated on: Sep 23, 2013 at 7:55 PM
Updated by: danroth27

V5.5: Complex types,Entity reference, Entity and a collection of them as function parameters

Currently, Web API only support primitive type and enum type as function parameters.
Now, ODL supports
.Complex types
.Entity reference
.Entity
.A collection of them
as function parameters.

Web API should support all of them.

Consider supporting parsing and generating key values in KeyValuePathSegment

So user doesn't need to call ODataUriUtils.ConvertToUriLiteral or
ODataUriUtils.ConvertFromUriLiteral to parse the id by himself.

Work Item Details

Original CodePlex Issue: Issue 674
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Dec 5, 2012 at 2:26 AM
Reported by: hongyes
Updated on: Sep 23, 2013 at 7:31 PM
Updated by: danroth27

Consider adding IConvertible support to Delta<T>

It's somewhat possible to deserialize Delta with Json.Net, and we've posted
a sample of how to do this to show a full solution. It would get a lot of
users closer if we added support for IConvertable conversions in the
TrySetValue method of Delta

We need to be careful about perf impact for OData scenarios.

Work Item Details

Original CodePlex Issue: Issue 1554
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Dec 14, 2013 at 1:53 AM
Reported by: nowakra
Updated on: Apr 17, 2014 at 9:42 AM
Updated by: zjufish

metadata is not exposed correctly for properties with query limitations

Create a model with an entity and some properties.
Limit anyone of them.
Query the $metadata url.
The metadata doesn't expose the limitation on the vocabulary for the property.

Work Item Details

Original CodePlex Issue: Issue 1451
Status: Proposed
Reason Closed: Unassigned
Assigned to: cysu
Reported on: Nov 25, 2013 at 2:11 AM
Reported by: jacalvar
Updated on: Dec 3, 2014 at 4:19 AM
Updated by: jorgeaguirre1

Support OData Uri Parse extension of ODL 6.7 release

#1. Problem:

ODL 6.7 supports

overriding default Uri parsing behavior, including:

-  Resolving property name 
-  Resolving type name 
-  Resolving navigation source name 
-  Resolving operation import name 
-  Resolving bound operation name 
-  Resolving function parameters 
-  Resolving entity set key 
-  Resolving binary operator node elements 

for detail: http://blogs.msdn.com/b/odatateam/archive/2014/09/05
/announcement-odatalib-6-7-0-release.aspx

#2. Secanio - case insensitive

For OData $filter/$sort queries, our output could potentially different
casings vs. the model. In this scenario the query parsing will fail.

For example, if my model has a "Name" property but my JSON outputs the
property as "name" I cannot use $filter=startswith(name,'Joe') which consumers
would expect.

Discussion reference: http://aspnetwebstack.codeplex.com/discussions/391903

Work Item Details

Original CodePlex Issue: Issue 366
Status: Active
Reason Closed: Unassigned
Assigned to: xuzhg
Reported on: Aug 24, 2012 at 5:41 PM
Reported by: jberd126
Updated on: Dec 24, 2014 at 6:10 AM
Updated by: xuzhg

ODataConventionModelBuilder doesn't work with MetadataTypeAttribute

This scenario is quite common in EF DB generated code. User can't change
generated code. So they have to use metadata type to specify the data
annotation attributes.

For example, I have model:

[MetadataType(typeof(TodoModel))]
public class Todo
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class TodoModel
{
    [Required]
    public string Name { get; set; }
}

   static IEdmModel GetEdmModel()
    {
        ODataConventionModelBuilder builder = new ODataConventionModelBuilder();
        builder.EntitySet<Todo>("Todo");
        return builder.GetEdmModel();
    }

The required attribute will not be recognized in conventions.

Work Item Details

Original CodePlex Issue: Issue 515
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Oct 6, 2012 at 12:43 AM
Reported by: hongyes
Updated on: Apr 30, 2014 at 5:29 PM
Updated by: lybax

$count is evaluated prematurely at the call queryOptions.ApplyTo

internal static class ExpressionHelpers
{
    public static long Count(IQueryable query, Type type)
    {
        MethodInfo countMethod = ExpressionHelperMethods.QueryableCountGeneric.MakeGenericMethod(type);
        return (long)countMethod.Invoke(null, new object[] { query });
    }

A query
http://localhost:31181/api/northwind/Products?$count=true
will evaluate the query expression prematurely at the call
queryable = queryOptions.ApplyTo(queryable, settings);

This breaks RESTier, specifically, in DomainControllers.GetQuery method.
Since at that time QuerySourcer has not intervened in, the placeholder class QueryableSource will be queried against, and exception will be thrown.

Call stack:

System.Web.OData.dll!System.Web.OData.ExpressionHelpers.Count(System.Linq.IQueryable query, System.Type type) Line 18 C#
System.Web.OData.dll!System.Web.OData.Query.CountQueryOption.GetEntityCount(System.Linq.IQueryable query) Line 138 C#
System.Web.OData.dll!System.Web.OData.Query.ODataQueryOptions.ApplyTo(System.Linq.IQueryable query, System.Web.OData.Query.ODataQuerySettings querySettings) Line 239 C#

It's better to support automatically adding actions and functions in ODataConventionModelBuilder.

Now it is need to add actions and functions in this way:

        var actionConfiguration = employee.Action("AddSkill");
        actionConfiguration.Parameter<Skill>("skill");
        actionConfiguration.ReturnsCollection<Skill>();

It will be more convenient If it is generated with reflection.

Work Item Details

Original CodePlex Issue: Issue 1587
Status: Proposed
Reason Closed: Unassigned
Assigned to: xuzhg
Reported on: Dec 25, 2013 at 12:25 PM
Reported by: jinfutan
Updated on: Jan 28, 2014 at 6:44 AM
Updated by: xuzhg

Enhanced Collection patching

Once this gets patched ,
it would be awesome to have item level patching on all
collections/dictionaries. RavenDB does this pretty good.

Work Item Details

Original CodePlex Issue: Issue 903
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Mar 13, 2013 at 1:29 PM
Reported by: blake05
Updated on: Oct 15, 2013 at 9:22 PM
Updated by: Lenne231

Support OData Uri Parse extension of ODL 6.7 release

#1. Problem:

ODL 6.7 supports

overriding default Uri parsing behavior, including:

-  Resolving property name 
-  Resolving type name 
-  Resolving navigation source name 
-  Resolving operation import name 
-  Resolving bound operation name 
-  Resolving function parameters 
-  Resolving entity set key 
-  Resolving binary operator node elements 

for detail: [ http://blogs.msdn.com/b/odatateam/archive/2014/09/05
/announcement-odatalib-6-7-0-release.aspx
](http://blogs.msdn.com/b/odatateam/archive/2014/09/05/announcement-
odatalib-6-7-0-release.aspx)
#2. Secanio - case insensitive

For OData $filter/$sort queries, our output could potentially different
casings vs. the model. In this scenario the query parsing will fail.

For example, if my model has a "Name" property but my JSON outputs the
property as "name" I cannot use $filter=startswith(name,'Joe') which consumers
would expect.

Discussion reference: http://aspnetwebstack.codeplex.com/discussions/391903

Work Item Details

Original CodePlex Issue: Issue 366
Status: Active
Reason Closed: Unassigned
Assigned to: xuzhg
Reported on: Aug 24, 2012 at 5:41 PM
Reported by: jberd126
Updated on: Dec 24, 2014 at 6:10 AM
Updated by: xuzhg

double.NaN, decimal.MaxValue doesn't work

ODataLib UriParser doesn't work on some condition values, such as double.NaN,
decimal.MaxValue, etc.
So, WebApi can't work on them.

Please track on the ODL fix and make these condition values work.

Work Item Details

Original CodePlex Issue: Issue 1560
Status: Proposed
Reason Closed: Unassigned
Assigned to: xuzhg
Reported on: Dec 17, 2013 at 6:08 AM
Reported by: xuzhg
Updated on: Dec 17, 2013 at 6:08 AM
Updated by: xuzhg

Cannot use $select on value objects

OData endpoints sometimes need to serve up complex objects with quite a few
root level properties. Typically these are modeled as value objects, so I
might have the following:

• Customer entity
• Value object for PrimaryAddress
• Entity association for Country

Typically consumers want to select fields from value objects in the same
manner as fields from entities. A consumer can legally select child fields
from entities like this ($expand must be used):

• /odata/customers?$top=10&$expand=Country&$select=Country/Name

Whereas if a consumer tries to select fields from value objects like this:

• /odata/customers?$top=10&$select=PrimaryAddress/Line1

Then the following error is returned:

• 'Inner or start path segments must be navigation properties in $select'

I understand that value objects like PrimaryAddress are not navigation
properties so I cannot use $expand with them. It feels natural for consumers
to be able to pull just the fields they need via $select though.

So just thought I'd ask if this is expected behaviour or if this is expected
to change for the next Web API release?

Work Item Details

Original CodePlex Issue: Issue 1142
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jul 17, 2013 at 1:46 PM
Reported by: GaryArcher
Updated on: Sep 23, 2013 at 7:54 PM
Updated by: danroth27

Custom functions in $filter (need to fix the function binder to enable this)

Consider the strategy for interface property in convention model builder

Currently, we don't do anything special for interface. It will be added as an
entity type or complex type depending on the entity key convention.

We can ignore interface property in convention model builder as it sounds like
not a supported scenario.

Or we can make interface same as abstract class, then we need to change our
convention to mark it as abstract in edm model.

Work Item Details

Original CodePlex Issue: Issue 514
Status: Active
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Oct 6, 2012 at 12:29 AM
Reported by: hongyes
Updated on: Sep 19, 2013 at 11:30 PM
Updated by: danroth27

Add foreign key information to the associations in the $metadata document

When there is an entity in a model that has an entity that explicitly exposes
the foreign key of an association to another entity, make that information
visible and available in the $metadata document.

For example:

<EntityType Name="Customer">
<Key>
<PropertyRef Name="Id"/>
</Key>
<Property xmlns:p6="http://schemas.microsoft.com/ado/2009/02/edm/annotation" Name="Id" Type="Edm.Int32" Nullable="false" p6:StoreGeneratedPattern="Identity"/>
<Property Name="Name" Type="Edm.String" MaxLength="Max" FixedLength="false" Unicode="true"/>
<NavigationProperty Name="Orders" Relationship="WcfDataServicesForeignKey.Customer_Orders" ToRole="Customer_Orders_Target" FromRole="Customer_Orders_Source"/>
</EntityType>
<EntityType Name="Order">
<Key>
<PropertyRef Name="Id"/>
</Key>
<Property xmlns:p6="http://schemas.microsoft.com/ado/2009/02/edm/annotation" Name="Id" Type="Edm.Int32" Nullable="false" p6:StoreGeneratedPattern="Identity"/>
<Property Name="CustomerId" Type="Edm.Int32" Nullable="false"/>
<Property Name="Purchased" Type="Edm.DateTime" Nullable="false"/>
<Property Name="Total" Type="Edm.Double" Nullable="false"/>
</EntityType>
<Association Name="Customer_Orders">
<End Type="WcfDataServicesForeignKey.Customer" Role="Customer_Orders_Source" Multiplicity="1">
<OnDelete Action="Cascade"/>
</End>
<End Type="WcfDataServicesForeignKey.Order" Role="Customer_Orders_Target" Multiplicity="*"/>
<ReferentialConstraint>
<Principal Role="Customer_Orders_Source">
<PropertyRef Name="Id"/>
</Principal>
<Dependent Role="Customer_Orders_Target">
<PropertyRef Name="CustomerId"/>
</Dependent>
</ReferentialConstraint>
</Association>

This is the behavior WCF Data Services implement, and it's required for third
party OData client libraries like breeze.js to work against Web API OData
properly.

Work Item Details

Original CodePlex Issue: Issue 1094
Status: Active
Reason Closed: Unassigned
Assigned to: xuzhg
Reported on: Jun 18, 2013 at 11:54 PM
Reported by: jacalvar
Updated on: Dec 24, 2014 at 6:08 AM
Updated by: xuzhg

V5.5: Support for Abstract types with no properties

Support abstract types (entity/complex) without any properties.

V5.5: Support of Derived EntityTypes to define their own keys

It's allowed to define their own keys on the derived entity types only if the base types don't contain any keys:

Here's the example:
< EntityType Name="baseEntity" Abstract="true" />
< EntityType Name="account" BaseType="ns.crmbaseentity">
< key>
< Property Name="accountid" Type="Edm.Guid" />
< /key>
< /EntityType>

Thanks.

Consider improving OData link generation with a fluent api

When generating a link for an OData resource, the current experience is as
follows.

Url.ODataLink(
            new EntitySetPathSegment("People"),
            new KeyValuePathSegment(key));

Consider improving the link generation experience by making use of a fluent
api.

This is only an option, not the specific proposal:

Url.ODataLink(ODataPath.EntitySet<People>("people").Key(5).Property(p => p.Name))

Work Item Details

Original CodePlex Issue: Issue 929
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Mar 22, 2013 at 7:38 PM
Reported by: jacalvar
Updated on: Sep 23, 2013 at 8:01 PM
Updated by: danroth27

Named Streams

WCF DataServices enables attaching streams to entities by marking them with
HasStreamAttribute and implementing IDataServiceStreamProvider. There is
currently no equivalent support in WebApi.

Adding support would enable a NuGet compatible data source to be implemented
in WebApi, where today it is not possible to provide the src attribute on the
content element (see http://nuget.org/api/v2/Packages/?$top=1
for an example).

Work Item Details

Original CodePlex Issue: Issue 770
Status: Proposed
Reason Closed: Unassigned
Assigned to: Unassigned
Reported on: Jan 14, 2013 at 6:14 PM
Reported by: chriseldredge
Updated on: Sep 23, 2013 at 7:30 PM
Updated by: danroth27

V5.5: Support Edm.Date & Edm.TimeOfDay primitive data types

ODL announced the release of V6.8.0 as below:
http://www.nuget.org/packages/Microsoft.OData.Core/6.8.0

In this release, ODL supports two new primitive types: Edm.Date & Edm.TimeOfDay.

Customers need these two new types supported in Web API.