Support OData queries

[TimNilimaa]

Would love to see support for OData queries to functions, so that one could build an odata compliant service using Functions rather than an app service. OData supports .net core now, so the way to support this should be too far away. Today one might use parsers of the querystring but it doesn't work 100% of the time.

[ColbyTresness]

@mattchenderson

[josmithua]

This would be great!

[hanneslarsson]

We would really benefit from this. We are looking at moving away from Azure functions due to the missing support for OData. But would rather not as we really like the Azure Functions.

[christophedemey]

I also was looking for this feature and would like if u guys supported it, i am unable to move 2 projects at this point to azure functions because of the lack of odata support.

[aletc1]

I have a workaround while official support is being developed: https://github.com/aletc1/examples-odata-azure-functions,

Full details in: https://www.algohace.net/posts/odata-en-azure-functions-v2 (Spanish only)

[BHuber-PlanB]

We also wanna switch from Azure App Service to Azure Function. Would be great for our project too! Because we use OData in our Azure App Services we can't switch to Azure Functions.

[smokedlinq]

We had a simple need, support GET requests with odata syntax. Thanks to the extension method provided by @aletc1 I was able to spend a few hours this afternoon and came up with a simple binding extension that has support for the EnableQuery attribute as shown here.

[EnableQuery(MaxTop = 100, AllowedQueryOptions = AllowedQueryOptions.Select | AllowedQueryOptions.Filter | AllowedQueryOptions.Top)]
[FunctionName("products")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)] HttpRequest req,
    ODataQueryOptions<Product> odata,
    ILogger log)
{
    var data = new List<Product>
    {
        new Product { Sku = 1, Name = "Apple" },
        new Product { Sku = 2, Name = "Lettuce" }
    };

    return Task.FromResult<IActionResult>(new OkObjectResult(odata.ApplyTo(data.AsQueryable())));
}

[deepbass]

This would be super helpful for us to use in conjunction with Power BI rather than giving either raw database access or use an App Service 👍

[alexmartinezm]

Is there any workaround for v3?

[alexmartinezm]

Bear in mind that there's an open bug related to "select" clauses... https://github.com/OData/WebApi/issues/2118

[smokedlinq]

Is there any workaround for v3?

@alexmartinezm -- I just pushed an update that makes this work for v3 Azure Functions

[steven-pearson]

Great solution @smokedlinq Works just great! Are you going to publish as a Nuget package?

[smokedlinq]

Not sure. I'm the furthest thing from an OData expert. I'm pretty sure I shouldn't publish it with the Microsoft prefix on the NuGet package if I do, so I'll first have to come up with a project name/code. ;p

[crgarcia12]

+1 :)

[smokedlinq]

@alexmartinezm @steven-pearson FYI I just moved this over to a new repo for my function extensions and published a nuget package AzureFunctions.Extensions.OData.

[jacobmohl]

1+ Would be very nice to have official support for https://github.com/OData/aspnetcoreodata

[jhulbertpmn]

+1

[daisukei777]

+1

[CiroDiMarzo]

+1 please officially implement this. Thank you.

[challamzinniagroup]

This issue is 3 years old and is now onto its 3rd version of Azure Functions since the issue was raised. And still no OData implementation from Microsoft - only community workarounds.

How has this not been a priority? Does Microsoft feel that paging, sorting, and filtering of data is not important? Or that these features don't warrant an official framework solution?

Does anybody have any current workaround for Azure Functions v4; .Net6.0? This is bordering on being a deal-breaker for the platform as-is.

[apoorvmintri]

+1 please officially support this! without it, azure functions isn't working out to be a good option for api.

[gadusumi]

+1. Please officially add this to the product pipeline. Thank you!!

[mayank88mahajan]

Tagging @fabiocav to see if this being considered in the new Isolated model

[PatrikNorrgard]

Please add this support, we are now unable to move to Functions V4 / .Net 6 as the community workaround has stopped supporting it.

https://github.com/smokedlinq-archive/Microsoft.Azure.WebJobs.Extensions.OData

[david-nguyen]

Not ideal but consider creating an api and hosting it as a web app on azure.

[challamzinniagroup]

Not ideal but consider creating an api and hosting it as a web app on azure.

Apologies, I'm not sure if I understand what you are suggesting.

If you mean to avoid functions altogether and revert to the "old way" of doing things (.Net Core WebApis hosted as AppServices) - this is essentially the decision I have made in those instances where OData is required (which is almost every project). It's simply not practical to create a custom data fetching solution - this problem was solved years ago. Microsoft took three steps backwards on this with Functions and has remained there, giving zero indication as to whether they are even considering implementation of a basic feature.

For all the promise of serverless computing; Microsoft has not really been at the top of the game by a fair margin. Just as one small example of questionable priority decisions; Microsoft recently added Swagger/OpenAPI to Functions. And while I am all for this - there is no way this was more needed than formal OData support. OpenAPI is a nice to have while OData is a need.

[david-nguyen]

Not ideal but consider creating an api and hosting it as a web app on azure.

Apologies, I'm not sure if I understand what you are suggesting.

If you mean to avoid functions altogether and revert to the "old way" of doing things (.Net Core WebApis hosted as AppServices) - this is essentially the decision I have made in those instances where OData is required (which is almost every project). It's simply not practical to create a custom data fetching solution - this problem was solved years ago. Microsoft took three steps backwards on this with Functions and has remained there, giving zero indication as to whether they are even considering implementation of a basic feature.

For all the promise of serverless computing; Microsoft has not really been at the top of the game by a fair margin. Just as one small example of questionable priority decisions; Microsoft recently added Swagger/OpenAPI to Functions. And while I am all for this - there is no way this was more needed than formal OData support. OpenAPI is a nice to have while OData is a need.

Right that's why I said it is not ideal but given that microsoft has not addressed the issue for 3 years it's a possible solution.

[NSouth]

I love so much of what Functions represents, but then issues like this come up and remain unaddressed for years. These are things that prevent Functions from being an option for many users and businesses.

[ph-ict]

Another vote for this please. I have a need for a simple GET endpoint to fetch data from an EFCore data store. This is relatively simple to achieve in ASP.NET Core WebApi, but I really need the scalability, flexibility and lower overheads/maintenance of an Azure Function.

[kazman71]

Bumping the thread. This is a very nice feature that is BROKEN. Evidently it used to work. Are new features > broken old features?

[challamzinniagroup]

Bumping the thread. This is a very nice feature that is BROKEN. Evidently it used to work. Are new features > broken old features?

To my knowledge, this has never been implemented. Therefore it is not technically broken.

There was a community-produced solution for one of the legacy Function versions - but I do not believe that is functional on the new versions.

[jarvan-jiang]

https://github.com/xuzhg/WebApiSample/tree/main/AzureFuncDemo This one seems able to work for now.

[rtellez91]

So are there any plans of implement support for this in Azure Functions out of proc?

[DonnOMalley]

OData support missing from Functions is also preventing us from further adopting Functions. I know I'm late to this party but I wanted to give another +1 for this. We are using v4 Functions and could really use that official support for OData.

[apoorvmintriEM]

I have come to the realization that Functions/Lambda etc. are not worth it. You get locked in into using a particular cloud provider on top of its other issues such as no support of OData. I'll use 'Functions' and its alternatives, only when I am able to wrap my API to be able to run it as an Azure Function. 'Serverless' is as good as the marketing strategy employed for 'sugarless'.

[TimNilimaa]

I am starting to lean into the idea of closing this issue. While OData can be a great feature in some cases I see the need for odata less and less when we are looking at serverless and microservices. With improvements in tooling the need for a "strongly typed interface" such as OData. What are your thoughts?

[smokedlinq]

I tend to agree. With GraphQL gaining more usage I'd rather focus on providing that capability for functions.

[kazman71]

I mean you guys literally did nothing to solve it. Now just abandoning it? It’s cool we made a web app because you broke it and can’t fix it or just won’t fix it. Let it languish enough and wait for another tech that is not that new either.

[kazman71]

You guys should pull docs that day this is supported. People waste a lot of time with your incorrect docs.

[jacobmohl]

Still needed. The whole Microsoft ecosystem rely on OData (Graph, Dynamics 365 ect). The possibility to create similar developer experiences on custom APIs is a must have.

[ph-ict]

I agree with @jacobmohl, OData support is still needed. We have what's essentially a passthrough function (there's a little more to it) and had to fire up a whole web app for it because Functions simply couldn't do what we needed.