OData with EF Core / ASP.NET Core - Good or Bad?

Question

I've read a lot about OData with EF Core / ASP.NET Core. It seems to me that everybody has an opinion on this and It's gotten a bit confusing, so at the risk of sounding dumb, I have a few questions:

Please note:
! I'm NOT talking about the classic ASP.NET 4.6 or 4.7 with EF6 !
! I'm talking about ASP.NET Core with EF Core !

1. Considering building API - Is there stuff that EF Core alone couldn't handle as well as EF Core with OData?

2. Considering building API - Is it not better to build clean RESTful APIs instead of OData style APIs?

3. Isn't implementing OData stuff sacrificing best practices for convenience?

4. What about long term? Aren't ASP.NET Core + EF Core being built with speed and efficiency in mind and thus won't they be faster and more efficient on their own?

Answer 1

I will go with Shawn Wildermuth's advice that I found on Pluralsight:

OData means that queries are on the client so that versioning OData services becomes risky and it feels like MS is moving away from it so I don't have confidence in the long-term viability of it either.

Answer 2

OData on ASP.NET Core/EF Core works very well. Versioning can be accomplished with microsofts versioning api. I don't necessarily see MS abandoning this technology. There main api (ms graph) is odata 4 compatible.

Using Odata on top of EF Core is really enjoyable for many use cases. Especially the querying part I like a lot. For implementing writes/commands I usually fall back to webapi/Mediatr.

Here https://www.jannikbuschke.de/blog/cqrs-with-mediatr-and-odata/ and here https://www.jannikbuschke.de/blog/odata-getting-started/ I wrote some thoughts/guides on this topic.

One downside is tooling and community. There is not a whole lot out there.