Lightweight version

[JohnGalt1717]

Currently there doesn't appear to be a way to just get $filter, $select, $top, $take, $count. It's all or nothing and you get all of the EDM. I would like to see a stripped down version of this for .NET Core 3.0 that has the commands broken out so that they alone can be applied with nothing else to any webapi endpoint that has the right attribute (and a way to have it apply to all endpoints that return ActionResult)

Why?

Because the vast majority of us are not exposing our EDM. We're exposing a REST API and want to give users of the api the ability to return subsets of data easily without having to reimplement the logic over and over again. Odata's logic for this is sound and shouldn't be reinvented.

[KanishManuja-MS]

@JohnGalt1717 I am not sure if I understood your question. You can enable a subset of the query options. For instance, if you only want to support $filter, you can without enabling $select.

[JohnGalt1717]

It's a feature request.

I want Odata to work without any EDM functionality as a separate library that does nothing but $filter, $select, $top, $take, $count etc. I don't want to expose my EDM, I don't want any of the other overhead of Odata, I just want the library that acts upon IQueryable WebApi responses, which is what the vast majority of people adding this library are actually doing.

The rest is ill-advised for anything other than LOB intranet stuff anyhow because you should never be returning EDM objects and always returning DTOs.

The result would be that for the vast majority of people much less overhead and a much safer implementation of what they actually need. Hence splitting out the $filter etc. from the rest would be highly desirable.

[NetTecture]

Dude, you are ranting - and sadly not with a too much sense at times. Let me explain:

which is what the vast majority of people adding this library are actually doing.

Only those that are not using tooling and i.e. pointing Excel to an Odata source. Or using code generators to - well - generate code for a client. And work in small enough projjects that this is not an issue, which I sort of do not see. Every single client I use comes out of a generator, and that generator is using the $metadata endpoint to know what is possible. And I regularly use Excel and report generators to actually generate reports vs. my odata endpoints.

you should never be returning EDM objects and always returning DTOs.

EDM objects ARE DTO's and nothing else. EDM defines what the data surface looks like, nothing else. If you return EF Core (i.e. database side) objects there, you already do more wrong than right. And that is when you get into those issues. If you ahve more than DTO in the EDM objects, you make something seriously wrong already, in my opinion.

EDM objects in my world are separate API objects that are nothing else than DTO - and actually can also be used from the client side. I do that using AutoMapper to expose $filter and other functionality through a LINQ mapper - in classic .net without any problems, in .net core with a LOT of problems as there is nosensible combo right now that works (as in: efcore 2.2 is broken, 3.0 requires netcoreapp 3.0 / netstandard 2.1, both are not really working together, so there is no common ground to odata right now (but hopefully coming), except dropping efcore and using ef classic (for which a third party version exists that runs in 2.2).

I am all in for a lightweight version - I would love to be able to annotate my edm classes with all kinds of attributes WITHOUT having to load the whole asp.net core server in (not a joke - there is no separation there), but your arguments are logcially not conclusive.

I am also no sure what you mean with "less overhead". I found odata as protocol to have not a lot of overhead - yes, the json is clumsy at times, but that is needed for all the advanved features. client library performance is another issue, but that is something different.

Not that I would object a better modulariy - on the contrary. But pelase with better arguments. And no, return ActionResult is ABSOLUTELY NOT POSSIBLE. Seriously. Have you actually LOOKED at what $filter etc. allow? Because you basically NEED an IQueryable there - latest when you start with count, subcount, INLINE count and get into the more complex methods - I doubt most people would even know how to start putting together the query graphs for some of this stuff. Kudos to the odata team for that - I am only touching that area for security (filter out things) and to identify whether or not EFCOre can handle a query (if not I load all data into memory - yes, bad, but I hope still for efcore 3.0 and odata this year) and that already is VERY complex. If you demand people acutally do $filter and then return the data manually you seriously - very seriously - understimate the complexity of that part.

[JohnGalt1717]

@NetTecture Dude: I use ActionResult<IQueryable> all of the time. The rest of your rant is a distraction.

Stop exposing your data model!

All I want to do is provide an IQueryable and let customers filter, select and page as they wish based on that. I don't want them to have anything else. Obviously paging is easy and I don't need oData really. Select and filter are harder.

All of the rest of the oData stuff is WAY more than the vast majority of people need. Which is why they go to graphQL since this project is so brutally neglected as previously stated by others.

If the odata team would focus on $filter, $select, $take, $skip and $count and just give up on the rest of the stuff that's designed for internal line of business apps that are taking short cuts, this project would be far more maintainable.

[robertmclaws]

Guys, be civil please. Seriously. This is a feature request not an architectural discussion.

WebAPI 2 used to have the ability to opt into the URL syntax without the EDM stuff. It looks like that went away in .NET Core. It might be possible to bring it back in the .NET Core 3.0 Routing refactor, but that would take some time. We talked about it a little bit during the RESTier Community Standup this week. https://www.youtube.com/watch?v=2Pt0dz3LsYE