[vNext] Port ASP.NET Web API OData to ASP.NET 5/MVC 6

[kevinchalet]

I expect Web API OData to be really painful to port given that ASP.NET 5 and MVC 6 are radically different from the previous versions, but I think it's definitely worth it (sure, that's a totally biased opinion... I'm a huge fan of OData :dancer:).

For a complete port, we'd need a .NET core version of the ODataLib and EdmLib, but targeting aspnet50 might be a reasonable objective for a first step.

I'll probably start working on a straight aspnet50 port in the next couple of days, so let me know if you wanna participate :smile:

[congysu]

@PinpointTownes Thank you:) Let's see how we can provide .NET core version of the ODataLib and EdmLib to you. Shall we set up a phone call on this?

[kevinchalet]

@congysu thank you for your interest! :sake:

A few remarks concerning my progression:

• I almost got rid of HttpRequestMessage and HttpResponseMessage and replaced them with the new HttpContext. It was painful, but it's now done. That said, there is still a place I can't remove them from yet: in MediaTypeMapping (because Microsoft.Net.Http.Headers doesn't seem to have an equivalent for that). I'll ping @Tratcher when he's back.
• I removed the batching support from the first bits: I realize that it's of course a crucial feature, but MVC 6 doesn't support it yet, and it'll likely be implemented at the middleware level. This would need much more thinking, so I prefer removing it for now.
• I'm still undecided concerning OData routing. In the first bits, I removed the custom action selector and all the conventions to exclusively favor the attribute routing approach (that'll become the first-class citizen in MVC 6). This new version might also be a great opportunity to unify ODataRoute and Route/HttpGet attributes. The first tests using standard MVC 6 attributes are extremely encouraging, but only one EDM model per app is supported with this approach. Comments are welcome on these points :smile:

public class MyController
{
    [HttpGet("Entities")]
    public IActionResult Get()
    {
        return new ObjectResult(new[]
        {
            new MyEntity { ID = 4 },
            new MyEntity { ID = 5 }
        });
    }

    [HttpGet("Entities({id})")]
    public object Get(int id, ODataQueryOptions<MyEntity> options)
    {
        return new MyEntity { ID = id };
    }

    [HttpGet("Entities({id})/Children")]
    public object GetChildren(int id)
    {
        return new ObjectResult(new[]
        {
            new MyEntity { ID = 4 },
            new MyEntity { ID = 5 }
        });
    }
}

• MVC 6 now supports POCO controllers (i.e controllers that don't derive from the Controller base class). I'm not necessarily a fan of this feature, but I think we should support it. Of course, we'd still need a way to determine whether a controller/action is an OData one, but I wonder if we shouldn't simply replace it by the following assumption: if the OData path handler recognizes an OData path, assume that it is an OData request and that the controller that will handle the request is an OData controller, even if it doesn't derive from ODataController.
• I had to update EdmLibHelpers.GetMatchingTypes to use the callcontext static service provider exposed by KRE to retrieve an IAssemblyProvider (because you can't just use the default AssemblyProvider implemention, as it needs constructor parameters you can't easily import). This is of course an anti-pattern, but flowing an IAssemblyProvider is not option either (you can import it via ODataSerializerContext, but not from Delta<>, that relies on EdmLibHelpers.IsNullable but doesn't expose any context). I wonder if we shouldn't simply store the CLR type information directly in the EDM model (maybe via an annotation?) and stop using the loaded assemblies. Any thoughts?

private static IEnumerable<Type> GetMatchingTypes(string edmFullName)
{
    var assemblyProvider = CallContextServiceLocator.Locator.ServiceProvider.GetRequiredService<IAssemblyProvider>();

    return TypeHelper.GetLoadedTypes(assemblyProvider).Where(t => t.IsPublic && t.EdmFullName() == edmFullName);
}

• The tests will have to be updated to support xUnit 2 and its new K runner. I think we should remove Microsoft.TestCommon. Functional tests might be a nice addition.

Concerning ODataLib and EdmLib, I think that it would be easier to move to the new project.json stuff to easily support .NET, .NET Core and the different portable targets.

I'll try to share my current bits ASAP :soon:

If you want to, you can ping me on JabbR (#aspnetwebapi, #aspnetvnext or #odata)

[kevinchalet]

Gooood morning! :alarm_clock:

As promised, here are the first bits of the vNext port I worked on: https://github.com/PinpointTownes/WebApi

Of course, it's still a work in progress: tons of things have been removed (e.g OData routing or V3 support), updated, or replaced (e.g message handlers) and thousands of tests still need to be ported to xUnit 2, but things are finally starting to fall into place.

If you want to help porting the unit tests (@lewischeng-ms, I need you :smile:), don't hesitate to ping me for a write access.

That would be great if we could find a few minutes to talk about the in-depth details on the #odata room (https://jabbr.net/#/rooms/odata)

[lewischeng-ms]

@PinpointTownes Thanks! I am looking at your code and will share you with any insight from the code.

[kevinchalet]

@lewischeng-ms thanks!

A few notes:

• This is mostly a straight port: I tried to leave the code as-is when no changes were required (except serialization/deserialization, which is now async). That said, code guidelines used by the ASP.NET team have changed, and they now favor the use var everywhere approach. This makes the code more readable, and I think we should opt for var.
• Concerning the way EdmModel should be injected in the current context request, I'm still undecided. Maybe we should simply support a unique model per app for the first bits and store it in the incoming ODataOptions (that will be similar to MvcOptions) and see with the ASP.NET team if they have plans for multitenant/separated configurations support?
• I really think we should make EnableQueryAttribute less magic and remove on-the-fly EDM model creation: even if the IQueryable support is one of the most used feature of WCF/Web API OData, it's also one the most criticized aspect and a terrible brake for techies. Building an OData API should be a cautious act and we shouldn't hide the necessity to reduce the graph surface (e.g by marking critical navigation properties as non sortable, filterable or expandable).
• We should move the attributes used by Web API OData to their own project: having a separate "Models" project containing only the POCO models is a common thing in the real world, and depending on the whole ASP.NET thing to simply use the Contained/NotFilterable/Sortable/Expandable attributes is something we should try to avoid.

[kevinchalet]

@lewischeng-ms I see that you ported ODataLib and EdmLib to aspnetcore50 (now dnxcore50 btw): https://github.com/lewischeng-ms/vNext/blob/master/src/Microsoft.AspNet.OData/project.json#L3-L9

Is there a chance you could share the .nupkg? :smile:

[lewischeng-ms]

@PinpointTownes Sure. For ODataLib and EdmLib issues on vNext, let us move to https://github.com/OData/odata.net/issues/97 where I will update the latest progress there:smile:

[kevinchalet]

@lewischeng-ms @congysu don't hesitate to share your thoughts concerning the different points I mentioned :ghost:

For the "attributes" companion project, I'm not decided yet:

• Microsoft.OData.Annotations,
• Microsoft.AspNet.OData.Annotations,
• Microsoft.ComponentModel.DataAnnotations.OData,
• Microsoft.DataAnnotations.OData,
• System.ComponentModel.DataAnnotations.OData,
• System.DataAnnotations.OData.

The first one seems a good option, since it's not directly specific to ASP.NET nor Web API, which might be interesting for the ones who like sharing a portable "Models" project between their different apps.

Any thoughts?

[IDontEatSoap]

Awesome stuff Pinpoint :+1:

Is this the main force behind OData on vNext? I couldn't find anything else.

If so, do we have a dev branch here for people working on the upgrade?

Cheers

[kevinchalet]

@IDontEatSoap thanks! :family:

Is this the main force behind OData on vNext? I couldn't find anything else.

It looks like the OData and the ASP.NET teams prefer working on their own version and have a design review before touching the code (see https://github.com/aspnet/Mvc/issues/650#issuecomment-81171753). Not sure if it's a high priority item though (at least, it was clearly not when I asked David Fowler on JabbR a few weeks ago). So my mission here is now done (I'll simply provide feedback if they want me to).

If you're interested, you can take a look at https://github.com/PinpointTownes/WebApi, but please remember that it's an early prototype - probably full of bugs - that won't reflect the final version :smile:

[IDontEatSoap]

Haha I'm not surprised. There's a carrot in a shape of a KPI somewhere for someone to chase probably.

But I am suprised to see that there's nothing being done around OData by the ASP.NET msft people... Their team blog mentions this post as an "early investigation" on OData around vNext, but without an official branch....

Architecture is definitely the first thing to define. But hey, OData is not rocket science...

Well, I just hope OData on asp.net 5 supports CLR's DateTime. If there's something we could do outside corp to shed some light inside architects minds to make it happen it would be great.

[kevinchalet]

Haha I'm not surprised. There's a carrot in a shape of a KPI somewhere for someone to chase probably.

So true :smile: (if I was teasing, I'd even say that some people at MSFT still have trouble understanding the real definition of "an open source community", but heh, I'm not :smile:)

But I am suprised to see that there's nothing being done around OData by the ASP.NET msft people... Their team blog mentions this post as an "early investigation" on OData around vNext, but without an official branch....

:+1: The only official branch that I know of is the experimental playground used by @lewischeng-ms: https://github.com/lewischeng-ms/vNext

I can perfectly understand they prefer working on their own port instead of using what's offered by the community, but the lack of communication is a bit worrying. Since the conference call I had with @congysu and his team, I have listed a few points that are still not commented. I'm totally convinced there's a relationship between the low adoption rate of OData and this erratic communication.

Architecture is definitely the first thing to define. But hey, OData is not rocket science...

My idea was to port the basic/primitive blocks of Web API OData (serialization, deserialization, querying support) and start reviewing the current design with a working prototype.

Well, I just hope OData on asp.net 5 supports CLR's DateTime. If there's something we could do outside corp to shed some light inside architects minds to make it happen it would be great.

:+1: Given that they recently brought back this support in Web API OData, that would be suicidal to remove it from the vNext port.

[markdstafford]

Please let me apologize for any confusion and/or frustration we may have caused in our management of this particular contribution. Let me try to clarify a bit what's been happening behind the scenes. I apologized in advance if this is more detail than you wanted, but hey... at least you'll know what's happening.

First of all, @PinpointTownes , we really, sincerely appreciate both your enthusiasm and your desire to contribute to this repository. The biggest issue is that we frankly haven't made a firm decision as to whether our support in vNext will be a straight port or a deeper rethink of the overall architecture. OData will obviously have a presence there, we are just debating the details.

On the one hand we could do a straight port. This would obviously be ideal for existing customers, but it would come with the same overhead we have today in Web API OData. We want to improve not incrementally but exponentially. Ideally creating a REST API that follows OData conventions would be a matter of only a few lines of code. This would be tough to do with a straight port.

Another alternative would be to do a dramatic rewrite. Make things really dead simple (but keep the flexibility of Web API OData so we don't run into the cliff WCF Data Services customers ran into). This would be great for attracting new customers to OData but may be a deal-breaker for people with existing investments in Web API OData.

So part of the delay/confusion/vacillation has been that we're simply debating between these two alternatives, but most of that conversation is happening internally. :(

Here's my take on where we are. We want to find the middle ground, perhaps by bringing RESTier and Web API OData closer together or even possibly merging them into one stack. This middle ground would make it easy for existing Web API OData customers to migrate to vNext, and would make it enticing for new customers to adopt OData if all they have to do is add one or two lines of code.

Unfortunately this is ongoing thinking. The confusion you're seeing is an artifact of us having an active debate about the path to take. We're sorry that we haven't done a good enough job of communicating that to the outside community, but it's hard to know exactly what to share and what not to. Most of the world doesn't care about the minutiae of our design discussions. And we still have a lot to learn about open source - for instance, where the right place would be to have this conversation.

So. I think we need a bit of time at this point to stabilize our thinking on the path forward. Whatever direction we head, I'm super thankful that there's a version (buggy or not) that runs on vNext. Thank you for that!

And we'll try to figure out a better way to communicate exactly where we are in the process so that we don't make the same mistake again. Again, thank you, and we do hope that you stay an active part of the community.

P.S., we'll keep the support for CLR DateTime around.

[kevinchalet]

@markdstafford thank you very much for this detailed answer, it's really appreciated! :+1:

First of all, @PinpointTownes , we really, sincerely appreciate both your enthusiasm and your desire to contribute to this repository. The biggest issue is that we frankly haven't made a firm decision as to whether our support in vNext will be a straight port or a deeper rethink of the overall architecture. OData will obviously have a presence there, we are just debating the details.

On the one hand we could do a straight port. This would obviously be ideal for existing customers, but it would come with the same overhead we have today in Web API OData. We want to improve not incrementally but exponentially. Ideally creating a REST API that follows OData conventions would be a matter of only a few lines of code. This would be tough to do with a straight port.

Another alternative would be to do a dramatic rewrite. Make things really dead simple (but keep the flexibility of Web API OData so we don't run into the cliff WCF Data Services customers ran into). This would be great for attracting new customers to OData but may be a deal-breaker for people with existing investments in Web API OData.

Supporting both approaches would be ideal, actually (and would make everyone happy :smile:): advanced users should be able to use very strict conventions and apply fine-grained querying policies while beginners would indeed prefer reusing their DbContext and expose it "as-is". For me, having the core support in Web API OData and the automagical stuff in RESTier seems like a good compromise.

So part of the delay/confusion/vacillation has been that we're simply debating between these two alternatives, but most of that conversation is happening internally. :(

IMO, sharing your doubts with the community is a great thing, and will help you getting more feedback :+1:

Here's my take on where we are. We want to find the middle ground, perhaps by bringing RESTier and Web API OData closer together or even possibly merging them into one stack. This middle ground would make it easy for existing Web API OData customers to migrate to vNext, and would make it enticing for new customers to adopt OData if all they have to do is add one or two lines of code.

One concern I have with Web API OData/WCF Data Services is that simplicity hides the fact that even conventional models should be restricted to avoid data leakage or performance issues. For vNext, you could maybe choose an "opt-in" approach and create new Filterable/Sortable/Expandable attributes while still providing an option to use "opt-out" instead.

And we still have a lot to learn about open source - for instance, where the right place would be to have this conversation.

GitHub definitely seems the best place for that (thanks to its visibility), but JabbR is also useful for long discussions.

Again, thank you, and we do hope that you stay an active part of the community.

Thanks, I'll then make sure to annoy you with my feedback :smile:

[markdstafford]

For me, having the core support in Web API OData and the automagical stuff in RESTier seems like a good compromise.

Totally agree from a layering perspective. We are thinking a lot about whether they need to be distinct stacks, though.

One concern I have with Web API OData/WCF Data Services is that simplicity hides the fact that even conventional models should be restricted to avoid data leakage or performance issues. For vNext, you could maybe choose an "opt-in" approach and create new Filterable / Sortable / Expandable attributes while still providing an option to use "opt-out" instead.

This is great feedback. Tough to act on and still hold to the "you shouldn't have to be an OData expert do get value from OData" bar, but we absolutely hear you that having the right defaults is super important. This is probably a topic we need to come back to early in the design process (but after things have stabilized a bit).

GitHub definitely seems the best place for that (thanks to its visibility), but JabbR is also useful for long discussions.

Is JabbR too much of a Microsoft smell? While that might not matter for this particular stack, we obviously want to see OData adoption across all sorts of platforms, and having a one place for people to hang out/talk OData would be interesting. Our team has been experimenting with Slack lately. I don't like the barrier to getting in the first time, but once you're in, the experience is pretty good. Would love to hear your thoughts.

Thanks, I'll then make sure to annoy you with my feedback

Good. ;) We could benefit from a lot more people annoying us with feedback.

[lewischeng-ms]

@PinpointTownes Deeply sorry for the very late feedback... I had carefully gone through your port these days and our team just had a separate meeting today to discuss about your work. We really appreciate that. Though your prototype is based on a different point of view, it shows great value where we found many useful insights and techniques that could be incorporated into the vNext. I would like to share some basic thoughts upon your code and comments. Just hope you wouldn't think them to be too late:) And please feel free to express more ideas and feedbacks.

• That's pretty good style to use var everywhere and even more new C# 6.0 features as long as there is no confusion introduced. They could make the code clearer and simpler. In fact I have already began to use lambda expression on property members. That's a lot easier now to write a getter-only property.
• IAssemblyProvider. I met that problem too. I agree with you that it is annoying. Simply using the service exposed by KLR to enumerate all the loaded assemblies is not graceful and inefficient. Actually in my first bits, I took a CLR type from user and just search in that assembly (is it similar to what you said?). But what if there is a user who has model types stored in several assemblies? We have to figure out each situation carefully.
• EnableQueryAttribute. I have to say you are definitely an MVC expert. It is fairly a good design to have EnableQueryAttribute only including only public properties while moving the OnActionExecuted logic to ODataQueryActionFilter. Personally I think that really fits well into the single responsibility principle.
• ODataMediaTypeInputFormatter and ODataMediaTypeOutputFormatter. When moving to vNext, they are what we have to implement in any case. Pretty much thanks for splitting the original ODataMediaTypeFormatter into these two refined components. Now we are considering three options: 1) continue to rely on ODataLib to do serialization and deserialization where I think your implementation is good enough; 2) get some context info from ODataLib and directly use Json.NET to handle serialization and deserialization; 3) 'plug' Json.NET into ODataLib. The latter two aim to improve effiency and enable more flexability.
• Attributes companion project. Personally I don't have strong opinion on that so far:P But just regarding the names, I think maybe we should avoid using Annotation there because it may get confusing when there is a totally different concept 'annotation' lying in OData domain. Maybe we should hear more from you and have a better understanding of your perspective.
• per-request model v.s. per-app model. I think your suggestion is nice but we do have a few customer scenarios that ask for per-request model. Of course we can completely implement a new service called ODataOptions (as you suggested) to store stuff that can be safely treated as global unique to the application.

Since we are still at very early stage of investigation, we are so sorry that we only have limited information to share. But we will definitely keep sharing and discuss more with the public. And we are always striving to become more open and more inclusive to the world. Thus I would just encourage you to keep doing what you think is right and what you think is worth doing even if we may have different opinions. Whether or not an early prototype or feature could finally make it into the product branch, the values of it are always there.

Again, great thanks to you and we would certainly love to see your feedback and contribution to OData in the future!

[kevinchalet]

@markdstafford

Is JabbR too much of a Microsoft smell? While that might not matter for this particular stack, we obviously want to see OData adoption across all sorts of platforms, and having a one place for people to hang out/talk OData would be interesting. Our team has been experimenting with Slack lately. I don't like the barrier to getting in the first time, but once you're in, the experience is pretty good. Would love to hear your thoughts.

JabbR is definitely MSFT users/developers' lair but that doesn't prevent more general rooms (like #DDD-CQRS-ES, #Xamarin, #AngularJS or #owin) from being really popular, even for people who don't use MSFT products or technologies. TBH, I've never tried Slack, but I'd be happy to fix that if you had a link you could share. gitter.im might also be an option, but I personally find it far less interactive.

@lewischeng-ms

Deeply sorry for the very late feedback... I had carefully gone through your port these days and our team just had a separate meeting today to discuss about your work. Just hope you wouldn't think them to be too late:) And please feel free to express more ideas and feedbacks.

No problem, it's never too late, specially for a product whose design meetings have just started :smile:

IAssemblyProvider. I met that problem too. I agree with you that it is annoying. Simply using the service exposed by KLR to enumerate all the loaded assemblies is not graceful and inefficient. Actually in my first bits, I took a CLR type from user and just search in that assembly (is it similar to what you said?). But what if there is a user who has model types stored in several assemblies? We have to figure out each situation carefully.

Yeah, it's really annoying. I even had to replace IAssemblyProvider by ILibraryManager because the default implementation only looks for assemblies referencing MVC 6, which might not be the case with entities included in a shared/portable project that doesn't reference MVC 6: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Core/DefaultAssemblyProvider.cs#L56 It's not ideal as it loads every dependency listed in project.json into memory (and their own dependencies).

Of course, using a custom assembly provider (like this one, that uses a fixed list of assemblies: https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNet.Mvc.Core/FixedSetAssemblyProvider.cs) might be an option, but we'd have to keep in mind that it would be shared with the rest of the MVC application, so people would have to list both their controllers assemblies and their entities assemblies.

My remark concerning the CLR type was not really about the way it should be resolved (using an assembly provider, directly using the library manager, etc.), but the place where it's done: IMHO, the CLR type resolution should be directly made in ODataModelBuilder.GetEdmModel, at startup time, where you can more easily get an ILibraryManager/IAssemblyProvider. Of course, "on-the-fly" EDM model creation would have to be removed (but it's a bad practice, IMHO).

EnableQueryAttribute. I have to say you are definitely an MVC expert. It is fairly a good design to have EnableQueryAttribute only including only public properties while moving the OnActionExecuted logic to ODataQueryActionFilter. Personally I think that really fits well into the single responsibility principle.

Thanks, sir! :smile:

ODataMediaTypeInputFormatter and ODataMediaTypeOutputFormatter. When moving to vNext, they are what we have to implement in any case. Pretty much thanks for splitting the original ODataMediaTypeFormatter into these two refined components. Now we are considering three options: 1) continue to rely on ODataLib to do serialization and deserialization where I think your implementation is good enough; 2) get some context info from ODataLib and directly use Json.NET to handle serialization and deserialization; 3) 'plug' Json.NET into ODataLib. The latter two aim to improve effiency and enable more flexability.

The third option sounds like the best of both worlds. I wonder if the second option wouldn't make the serialization/deserialization stuff far too dependent of JSON.NET, which would make ATOM support (is this even considered?) really hard to implement.

Attributes companion project. Personally I don't have strong opinion on that so far:P But just regarding the names, I think maybe we should avoid using Annotation there because it may get confusing when there is a totally different concept 'annotation' lying in OData domain. Maybe we should hear more from you and have a better understanding of your perspective.

When working on an application that includes both the OData server and the corresponding OData client (often an MVC facade), I usually prefer sharing a single portable project that contains the different entities used by the server and the client. This way, code comments and attributes can be easily reused between the different projects. Sadly, if you want to use Contained, NotFilterable or their friends, you need to reference Web API OData, which makes the entities project non portable. That would be great if you could put the attributes in a different project and make it fully portable (dnx451, dnxcore50, but also Xamarin iOS/Android, Windows Store and even Windows Phone).

per-request model v.s. per-app model. I think your suggestion is nice but we do have a few customer scenarios that ask for per-request model. Of course we can completely implement a new service called ODataOptions (as you suggested) to store stuff that can be safely treated as global unique to the application.

I realize that it's of course an important scenario, that probably needs to bring back ODataRoute and his friends. One question I have is how would you pick a specific EDM model using regular HttpGet/HttpPost/HttpPatch/HttpDelete attributes?

I also wonder if it shouldn't be handled directly by MVC or Routing.

Another option might be to bind the IEdmModel with ODataOptions and create as much options registrations as needed: a special IOptions<> (aka "options manager") would then pick the appropriate options instance depending on the request URI, on a specific header, on the vpath... Creating a whole new IEdmModelSelector might also be an option.

Since we are still at very early stage of investigation, we are so sorry that we only have limited information to share. But we will definitely keep sharing and discuss more with the public. And we are always striving to become more open and more inclusive to the world.

Wonderful, thanks! :+1:

Again, great thanks to you and we would certainly love to see your feedback and contribution to OData in the future!

Sure (I'll probably flood you with remarks concerning the odata.bind support in the next few days)

[lewischeng-ms]

@PinpointTownes

My remark concerning the CLR type was not really about the way it should be resolved (using an assembly provider, directly using the library manager, etc.), but the place where it's done: IMHO, the CLR type resolution should be directly made in ODataModelBuilder.GetEdmModel, at startup time, where you can more easily get an ILibraryManager/IAssemblyProvider. Of course, "on-the-fly" EDM model creation would have to be removed (but it's a bad practice, IMHO).

May I ask what are you referring to by saying "on-the-fly"? Do you mean the ODataConventionModelBuilder? Anyway, besides the advantage you mentioned that it is easier to get assembly provider to do assembly search at startup time, I think we can also cache the mapping result (between clr and edm types) in some place (of course it could be in the model as you suggested) to improve the efficiency of later lookup.

The third option sounds like the best of both worlds. I wonder if the second option wouldn't make the serialization/deserialization stuff far too dependent of JSON.NET, which would make ATOM support (is this even considered?) really hard to implement.

I think you are right. It could be that the second option would make serialization/deserialization too coupled with JSON.NET unless we find something as the intermediate representation like JObject and can be easily converted to/from it. For ATOM, we cannot say we would just give it up that way. But we do aim to make the data transferring more lightweight. So ATOM may be considered as an extension support aside from JSON if we choose the second option. For the third option, if we could make the ODataLib layer more "thin" (aka strip off the serialization/deserialization functionality), we would love to do that but unfortunately this is still under investigation since the logic behind the large codebase of ODataLib is so complicated...

When working on an application that includes both the OData server and the corresponding OData client (often an MVC facade), I usually prefer sharing a single portable project that contains the different entities used by the server and the client. This way, code comments and attributes can be easily reused between the different projects. Sadly, if you want to use Contained, NotFilterable or their friends, you need to reference Web API OData, which makes the entities project non portable. That would be great if you could put the attributes in a different project and make it fully portable (dnx451, dnxcore50, but also Xamarin iOS/Android, Windows Store and even Windows Phone).

I see...But I need to talk to our client colleagues next week to understand more about those scenarios involving both server and client.

I realize that it's of course an important scenario, that probably needs to bring back ODataRoute and his friends. One question I have is how would you pick a specific EDM model using regular HttpGet/HttpPost/HttpPatch/HttpDelete attributes?

This is currently done in OData routing by setting Model property of ODataProperties associated to that request. Regarding whether to use ODataRoute or simply the MVC routing, I think we may need to find that ultimate answer together:)

Another option might be to bind the IEdmModel with ODataOptions and create as much options registrations as needed: a special IOptions<> (aka "options manager") would then pick the appropriate options instance depending on the request URI, on a specific header, on the vpath... Creating a whole new IEdmModelSelector might also be an option.

That's a good idea. I guess that would definitely require ODataRoute to be there, huh? We parse the request URI, extract the headers and make choice of which controller/action to invoke, which set of 'options' to pick, and which model to pass.

Thanks:)

[ghost]

Is JabbR too much of a Microsoft smell? While that might not matter for this particular stack, we obviously want to see OData adoption across all sorts of platforms, and having a one place for people to hang out/talk OData would be interesting. Our team has been experimenting with Slack lately. I don't like the barrier to getting in the first time, but once you're in, the experience is pretty good. Would love to hear your thoughts.

Yes. I think either a google group / mailing list / or a Freenode IRC channel may be better choices than jabbr or slack. All have good cross platform support and match what many other open source projects do. I'll move this portion of the discussion to another issue because it's entirely orthogonal to this discussion.

[kevinchalet]

@lewischeng-ms

May I ask what are you referring to by saying "on-the-fly"? Do you mean the ODataConventionModelBuilder? Anyway, besides the advantage you mentioned that it is easier to get assembly provider to do assembly search at startup time, I think we can also cache the mapping result (between clr and edm types) in some place (of course it could be in the model as you suggested) to improve the efficiency of later lookup.

Sorry, I should have been clearer. Here's what I mean by "on-the-fly model": https://github.com/OData/WebApi/blob/master/OData/src/System.Web.OData/Extensions/HttpActionDescriptorExtensions.cs#L36-L42 https://github.com/OData/WebApi/blob/master/OData/src/System.Web.OData/OData/EnableQueryAttribute.cs#L614

I'm totally convinced that allowing "pure Web API projects" to use EnableQueryAttribute without explicitly creating an IEdmModel (and thus realizing that it's a risky operation) is really really bad.

[lewischeng-ms]

@PinpointTownes Thanks I got what you mean:) I agree that we should not arbitrarily mix OData stuff with "pure Web API" stuff and users should always explicitly specify an IEdmModel to use EnableQueryAttribute. However we have to find a balance here. In one hand, elementary users who don't know OData concepts (e.g., EntitySet, EntityType, ...) very well yet shall be able to ramp up soon and build up a relatively satisfying service. In the other hand, advanced users can carefully "tailor" their models according to each very specfic need and pass it to Web API OData. This kind of "on-the-fly" model creation you mentioned indeed seems not to be a reasonable solution but helping users of any level to easily build models that work as they want is definitely one of our primary goals:)

[kevinchalet]

@lewischeng-ms I agree, Web API OData should be relatively easy to set up :smile: To make the IEdmModel creation a breeze, you could consider adding new attributes to define entity sets directly on the entity class itself. The conventional model builder would then scan your assemblies and build an IEdmModel without having to manually call EntitySet.

Creating a new OData API would be as easy as calling services.AddOData() (for beginners) or services.AddOData(builder => builder.EntitySet<Product>("Products")) (for advanced users).

(as a side note, that would be great to make the conventions stuff public, so users could remove specific conventions from the default set or choose their own one)

[lewischeng-ms]

@PinpointTownes Your points are really helpful, thanks! I think it would be great if there is a graceful way to expose the magic of model building as some set and let users make smart decisions on what magic they want to apply. Of course the magic will not be limited to the given conventions anymore. Please feel free to correct me if I misinterpret your point :P

[kevinchalet]

Ding dong. Any news concerning the vNext port? :lollipop:

[lewischeng-ms]

Hi @PinpointTownes Thank you very much for your attention. This month our team members are all focusing on documentation and tooling support of OData to help the community adopt OData more easily and smoothly. We plan to formally start working on vNext in May and we will update our status by then:)

[kevinchalet]

Wonderful, thanks @lewischeng-ms :bow:

[ilmax]

Maybe this is the wrong place, if so please point me to the correct one. For odata vnext I would love to have ODataQueryOptions with enhanced support for custom mapping/aliasing.

This is useful when the entity type and the type the client uses are different (flattening/projection involved) or when exposing DTOs instead of data entities from web api controllers.

[lewischeng-ms]

@ilmax Thanks for your feedback. Actually we are considering to offer enough flexibility when constructing EDM model from the Clr types users give us in vNext. I think what you suggest can be done by this part of the work.

[jods4]

:+1: really waiting for this to happen.

[FlippieCoetser]

@lewischeng-ms, any progress to share yet? noticed you mentioned start date was in May...

[lewischeng-ms]

@FlippieCoetser We have completed an initial alpha version of it. Please see http://odata.github.io/WebApi/#07-07-6-0-0-alpha1 for detail and have a try. Any feedback would be warmly welcomed. We would like to apologize for the slow progress as the whole team was busy catching a very urgent schedule these two months. But we shall restart development on this before long. Thanks.

[FlippieCoetser]

@lewischeng-ms Great stuff! I already loaded the sample and all works well! I keep you posted.

[jods4]

@lewischeng-ms Excellent timing -- for me at least ;) You can be sure I'll try this and let you know if I encounter bugs or limitations. FYI I'm going to use it with a EF6 Oracle back-end inside ASP.NET 5 (I'm currently on beta 6).

[lewischeng-ms]

@FlippieCoetser @jods4 Thank you both for your support!

[jods4]

@lewischeng-ms I tried to include the library in my project but I couldn't get it to work. I have the impression that because the library currently references asp.net beta4, it won't work with a beta6 runtime.

BTW it could be easier if you aligned the beta labels with matching asp.net runtime. People using asp.net vnext know that it usually crashes horribly when you mix components from different beta releases, so it becomes natural to pay attention that all your references are in sync. If you don't want to label it beta, maybe you could call it -alpha4 at least, so that it's more obvious if my list of references is correct/compatible or not.

That said I would really like to test a build updated for newer betas if you can create one!

[jods4]

@lewischeng-ms Here's some early feedback:

1. I made it works in -beta6. It was really easy as I only had to update references inside project.json and change 8 context.ActionContext.XYZ by context.XYZ (the ActionContext property is now gone and flattend). If you want I can do a PR but this is really really trivial. I also had to change the global.json but I'm unsure what you would put in there.
2. Error reporting is really rough but I guess this is expected. When you get everything configured right, it seems to work.
3. I had to call app.UseOData<T>("odata") separately. When I tried to do it inside app.UseMvc(builder => builder.MapODataRoute<T>("odata")); it crashes, apparently because some assemblyResolver is null or something.
4. DefaultODataModelProvider.BuildEdmModel() is quite basic. When it goes through the public properties, it could skip those that don't implement IEnumerable<T>. It's a simple if (entityClrType == null) continue;. Currently it crashes with a NPE.
5. Otherwise it seems to work ok. Of course because only $filter works it's extremely limiting right now ;) The logical next step for me would be to implement the rest of IQueryable so that I can perform paging queries, searches, etc.

[lewischeng-ms]

@jods4 Thanks very much for your valuable feedback. Regarding the versioning problem, I think what you suggest is quite reasonable but we need to work out a more flexible solution for both of us because we have our own schedule and our progress is not strictly synced with AspNet vNext.

Of course, we warmly welcome your pull request to make it work with beta6. Please feel free to do so. We can have more focused talk on your PR then.

About app.UseOData<T> or app.UseMvc, we are still thinking of whether we want to use MVC routing or implement our own route or both. So the API now looks rough and unstable. Sorry about that:)

Upon other things you mentioned, we may consider adding to the next alpha version with higher priority. We know that using alpha versions and experiencing breaking changes are hard and annoying. But we would love to hear more feedback from early adopters like you, make it better and better. Thanks sincerely.

[a99cl208]

@lewischeng-ms Hi,

Is there any alpha/beta release train planning that has been defined, like asp.net team which seem to release a new beta each month from june to december. I ask you because the GitHub repo have no update since 2 months and i wonder if you are still working on it?

Thanks for you answers, and btw the new design i good i think, more lightweight.

[weitzhandler]

Awesome stuff going on in here! Thanks for everyone working on this! Any chance OData will ever become first class citizen and be integrated with WebAPI?

[jhermsen]

Hi @lewischeng-ms and @markdstafford, Any progress on the plans or development? Really looking forward to be using OData on ASP.Net 5 WebAPI, but currently missing to much functionality to properly use it.

[lewischeng-ms]

@a99cl208 @weitzhandler @jhermsen Really sorry for the very late response. Thank you all so much for your attention and great passion on OData Web API! Please be assured that we will absolutely not give up OData Web API on ASP.NET 5. The most important reason we are not particularly focusing on Web API for the time being is that we think the next brand-new version of OData Web API as a great oppotunity to involve the power of the community. We cannot just shut the door and do it ourselves. It is now an open world where we have no way to succeed without hearing the users' voice. On the other hand, our team is currently putting much effort on RESTier which is a turn-key solution to help users build OData services more easily. As for us, OData Web API vNext is also a critical building block if we want to make RESTier successful on ASP.NET 5. Actually the development of RESTier also helps us gradually form the shape of OData Web API vNext.

So please feel free to tell us your expectation or put forward your design proposal on OData Web API vNext. We promise to value each feedback, each idea and each pull request. And...we won't keep you wait so long!

Thanks again!

[ilmax]

@lewischeng-ms any news on this? I'm a bit worried about the absence of any information/plan about porting OData to vnext.

On the other hand, our team is currently putting much effort on RESTier which is a turn-key solution to help users build OData services more easily.

RESTier can be a turn-key solution, but IIRC is not supported on vnext and since vnext is coming close, developers start poking around with tools and OData doesn't seem to be at the party, nor any plan is shared on OData vnext.

I'm totally convinced that allowing "pure Web API projects" to use EnableQueryAttribute without explicitly creating an IEdmModel (and thus realizing that it's a risky operation) is really really bad.

Actually I'm using this approach quite often when 3rd party UI components (like grids) support OData for sorting and filtering operation, but I'm totally against ODataConventionModelBuilder usage to create a model "on the fly" and thus I end up every time creating my own model binder which gets the model from a IModelProvider service.

Hope to get any sort of info from OData team concerning vnext. Regards

[tan00001]

@PinpointTownes: Microsoft just ditched WCF Data Service in favor of this more "open" WebAPI OData approach, and now you think this is "really really bad"? We can deal with an approach that is more "chaotic", as long as it delivers on its promise of being more flexible. But now with its implementers doing a tug of war towards the abandoned WCF Data Service, we are not getting any benefits for taking this path, only chaos.

Current WebAPI OData implementation is really awful. It really does not deliver much. For example, if your database catalog has multiple schemas, and you want to serve them out in different subdirectories, you have to write a lot of code to override the base code. "Default" namespace name cannot be left blank, and has to be spelled out as "Default". How tacky is that? If you try to use their client generator to deal with a few different namespaces, you are out of luck unless you want to write a lot of code of your own. All of this are on top of the fact that you will have to write a ton of controllers.

WebAPI OData v4 is a big let down. Now it is falling so far behind vnext, one has to wonder its coders are really up to the task.

I'm totally convinced that allowing "pure Web API projects" to use EnableQueryAttribute without explicitly creating an IEdmModel (and thus realizing that it's a risky operation) is really really bad.

[lelong37]

@tan00001 totally disagree, anyhow, this thread is to move OData forward, not to downplay the folks that are hard at work for vNext. OData v4 is great, and overall OData is the greatest thing thats ever happen to REST especially from a query perspective. Hat's off to the team, and I have complete confidence in the direction of where the team and the community takes vNext.

[weitzhandler]

@tan00001 I totally agree with @lelong37.

[DenisBiondic]

@lewischeng-ms - is this the repo where the implementation is developed? OData WebApi vNext and OData Web API 6.0.0 alpha1

[lewischeng-ms]

@DenisBiondic I am not sure because the link you provided pointed to my personal repo:) The team's repo is https://github.com/OData/WebApi/tree/vNext.

[lelong37]

With ASP.NET v5 RC released @ Connect, just wondering if the team has a version of vNext that will run with latest bits (RC)?

[AndiRudi]

I tried to get that to work with the following packages

"Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
"Microsoft.AspNet.OData": "6.0.0-alpha1",
"Microsoft.OData.Core": "6.12.0"

But it seems that the [EnableQuery] attribute is not found?

[ghost]

Same to me as @AndiRudi wrote. Seem like it works only with Microsoft.AspNet.Mvc 6.0.0-beta4 version. Will OData package be updated to support rc1-final?