Azure-functions-host: Support Custom Http Routes + URI path parameters

Created on 25 May 2016 · 8Comments · Source: Azure/azure-functions-host

Currently only query string parameters like /api/foo?id=7 are supported. It would be nice if it supported URI path parameter binding also like /api/foo/7. Some RESTful services go further for things like /api/foo/7/bar/15, so some sort of arbitrary path-to-param mapper would be ideal, but personally I've never used that so just an ID would suffice for myself...

I arrived here from Stack Overflow

feature should-have

Source

josh-endries

👍2

Most helpful comment

any progress on this? its a feature I currently need

contractorwolf on 4 Sep 2016

👍2

All 8 comments

I think the more general issue is that we don't have support for custom routing.

davidebbo on 25 May 2016

😕1

Funny, I was just talking to @narensoni about treating the path property as a URI template and use that to drive how we populate things.

fabiocav on 25 May 2016

@davidebbo Good point. We can always get the path from the request and parse out pieces if we need to. The reason I ran into this in the first place was that a request to the /api/foo/7 URI resulted in a 4xx (I think 404). IMHO fancy parsing/config in the portal could wait until after requests can be routed through based on prefix.

josh-endries on 25 May 2016

Yes, custom routing would bring it all together, but the template addresses a different issue about how to populate named parameters for in/out bindings and arguments, which is a significant limitation when binding to POCOs and any other type supported by HTTP triggers aside from HttpRequestMessage. This would also make the process of defining URI bindings for your scenario pretty straight forward.

fabiocav on 25 May 2016

Was going to post the same request but found this issue already open. My needs are the same custom routing for urls like /api/foo/:id/:etc

As a side note it would be even nicer to be able to drop the /api but I'm assuming there is a technical limitation on why it is required. The use case here is being able to mirror existing apis on Azure functions and those apis might not have already started with /api.