Is Web Api 2 OData v4 supported?

Posts   
 
    
Emmanuel
User
Posts: 167
Joined: 13-Jan-2006
# Posted on: 12-Sep-2017 17:40:50   

I have a fairly complex schema that I need to support CRUD operations for with a REST API. I'd like to do this with OData v4 implemented as a Web Api 2 project.

I am running v5.2 and already have been using the LLBLGen framework (rather than EF) and don't want to switch to EF.

Can I do this? Is there any documentation on how to accomplish this (I couldn't find any)? Any advice? Any examples?

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 12-Sep-2017 18:53:52   

Have you read this: WCF Data Services support?

Posts: 19
Joined: 29-Jun-2017
# Posted on: 26-Sep-2017 22:41:46   

Thanks Walaa that is helpful for me. Q: I am using v5.3 EAP and .NET Core 2. I think from reading the page (you linked to) this documentation does not apply to .Net Core 2 (it says "The support is for .NET 4 and higher"). Am I wrong? Is there updated info/examples for using OData with .NET Core and v5.3 ? Thanks Edit: From https://github.com/OData/WebApi/issues/939 : perhaps this does not even exists yet.

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 27-Sep-2017 07:37:28   

Q: I am using v5.3 EAP and .NET Core 2. I think from reading the page (you linked to) this documentation does not apply to .Net Core 2 (it says "The support is for .NET 4 and higher"). Am I wrong? Is there updated info/examples for using OData with

That's the v.5.2 docs.

Edit: From https://github.com/OData/WebApi/issues/939 : perhaps this does not even exists yet.

Apparently, yes. disappointed

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 27-Sep-2017 09:48:43   

We don't support OData v4, as MS in all their wisdom decided to introduce OData v4 in a library that breaks compatibility with OData v1-3, api wise. So we could either pre-compile the code with OData v1-3 or OData v4, and we chose the latter. If you want OData v4 support, you have to compile the OData support classes library in the runtime sourcecode against the OData v4 library from Microsoft.

The v1-3 version doesn't support .NET core btw, it's for .NET full. It's also the last LLBLGen Pro version which will support OData at all, after that we'll publish the source on GitHub and people have to compile the code against the OData library from MS themselves.

Frans Bouma | Lead developer LLBLGen Pro
Posts: 19
Joined: 29-Jun-2017
# Posted on: 27-Sep-2017 19:35:50   

Thank you. 1) So: I understand "No ODATA for LLBLGen .NET Core, whatever the version of ODATA"; am I right? 2) ... or perhaps I can:

If you want OData v4 support, you have to compile the OData support classes library in the runtime sourcecode against the OData v4 library from Microsoft.

Will that ("...compile the OData support classes library in the runtime sourcecode...") work for .NET Core? 3) Not _directly _related to LLBLGen but: I get the feeling from your reply that ODATA is on its way out (ie is 'old technology'), (I understand though it's still used by Netflix, SAP, ...). Do you (or anyone who can help) have a suggested newer/better replacement technology? So many "standards", so little time disappointed Thanks. PS I understand Facebook is developing GraphQL https://github.com/graphql-dotnet/graphql-dotnet - is this the future?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 28-Sep-2017 10:48:33   

FrankMonroe wrote:

Thank you. 1) So: I understand "No ODATA for LLBLGen .NET Core, whatever the version of ODATA"; am I right?

In our case, that's right.

2) ... or perhaps I can:

If you want OData v4 support, you have to compile the OData support classes library in the runtime sourcecode against the OData v4 library from Microsoft.

Will that ("...compile the OData support classes library in the runtime sourcecode...") work for .NET Core?

The OData support classes built on top of the ORMSupportClasses so converting them to a .netstandard 2.0 project shouldn't be that painful, but you then indeed also need to make sure it works with the MS library for OData for .net core, which as they say, will contain breaking changes as well. The heart of the code though should be the same, i.e. the discovery of what elements to expose.

3) Not _directly _related to LLBLGen but: I get the feeling from your reply that ODATA is on its way out (ie is 'old technology'), (I understand though it's still used by Netflix, SAP, ...). Do you (or anyone who can help) have a suggested newer/better replacement technology? So many "standards", so little time disappointed

OData has always been a bit of an outcast. Its team is still alive it seems, but it's been a niche technique. It's easy to expose a datamodel without doing a lot of work, but in the end, what exactly do you want to provide? Most people I talked to who used it went back to using a normal WebAPI with a REST client, as they're more in control of what's exposed and in what way, i.e. they can control how the model is used, by providing a specific API for that.

Thanks. PS I understand Facebook is developing GraphQL https://github.com/graphql-dotnet/graphql-dotnet - is this the future?

Be careful with graphql, it contains patented code and FB hasn't released it under a patent-free license. I.o.w.: FB holds your code hostage with their patent clauses.

In the end, you can't avoid doing work, that's the key takeaway: you either have to formulate the queries in the client which then targets the OData API, or you have to formulate the queries in the service and expose the queries as methods in the webapi.

I'd pick the latter, even if it's only for security. Derived models in the designer help a great deal with that too: you can model the shape of what you want to expose with these without external exposure of your entity model. simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Emmanuel
User
Posts: 167
Joined: 13-Jan-2006
# Posted on: 28-Sep-2017 13:35:01   

Otis wrote:

Be careful with graphql, it contains patented code and FB hasn't released it under a patent-free license. I.o.w.: FB holds your code hostage with their patent clauses.

There is breaking news just about the time when you posted this wink Facebook has re-licenced GraphQL under the Open Web Foundation Agreement (OWFs) (https://medium.com/%40leeb/relicensing-the-graphql-specification-e7d07a52301b)

Otis wrote:

In the end, you can't avoid doing work, that's the key takeaway: you either have to formulate the queries in the client which then targets the OData API, or you have to formulate the queries in the service and expose the queries as methods in the webapi.

I'd pick the latter, even if it's only for security. Derived models in the designer help a great deal with that too: you can model the shape of what you want to expose with these without external exposure of your entity model. simple_smile

Yes, I have come to the same conclusion and have started work on a traditional REST API (although, I'll have a look at GraphQL for a future version of the app).

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 28-Sep-2017 15:08:05   

That's great news at least! simple_smile

Frans Bouma | Lead developer LLBLGen Pro