-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add POCO example with HTTP binding #401
Comments
In the example above, you're binding the HttpTrigger directly to a POCO, which is awesome, but is it possible to bind to literally both the HttpRequestMessage and a POCO at the same time? For example: Alternatively, it is possible to create a HttpResponseMessage without needing the bound request? |
You can do this, but you'd put the trigger attribute on just the POCO. So it would be:
HttpRequestMessage would then be populated in a similar manner as special objects like TraceWriter. |
Neat! Thanks for the info :) |
This feature is awesome! I stumbled upon it by accident when building .csx functions and it has been a lifesaver. For some reason I can't get this to work with the new VS 2017 tooling. Using either POCO or HttpRequestMessage works but not both at the same time. Maybe I'm missing something obvious? startup error: My signature is public static async Task Run([HttpTrigger(...)] POCO myObj, HttpRequestMessage req) |
@MikeStall can you take a look at the signature @frli shared above? |
With the new tooling and the configuration from attribute model, this is not currently supported. It is a gap we intend to address, but in the meantime, the only option when using the new tooling is to deserialize the object from the request yourself. |
@frli I am guessing that you are using the HttpRequestMessage to get headers/query parameters and/or for creating the response back? If it's headers/query params:
(then just build a response back rather then using the helpers off HttpRequestMessage) The HttpTrigger will bind the Header and Query dictionaries to the 2 dictionaries in the signature above, which is what we do. If we need anything more detailed then we just use the main request object and in the function deserialize the object. |
@FRI , @ahmedelnably - I filed Azure/azure-webjobs-sdk-extensions#273 to track fixing this in VS Tooling. |
@TheeJamesLee I needed to get a look at the headers and that did the trick, thank you! 👏 👍 Just to clarify my scenario and why I would need access to a POCO and something more raw at the same time: I have a generic json webhook trigger and a documentdb input with document lookup via id. The document id is well known and constructed from incoming attributes in the POCO posted in the http trigger and set using runtime bindings. For various reasons I also need access to the incoming http headers. Having access to both the POCO and the HttpRequestMessage (or the headers dictionary mentioned by @TheeJamesLee ) allows me to do this in a comfortable way. |
Resolved with Azure/azure-webjobs-sdk-extensions#284 . Should be available in the next deployment. |
i really need to be able to
because i am using durable f unction and i also have to return
|
What serializer are you using for this feature? I am running into issues with Guid properties on my POCOs. I have tried the usual Newtonsoft attributes and converters, without luck. Is there another way to customize the serialization logic? |
Most customers don't know you can bind to both an
HttpRequestMessage
and a POCO. We should add it to the docs.Example of POCO: https://github.com/Azure-Samples/functions-dotnet-codercards/blob/master/CoderCards/CardGenerator.cs#L47
The text was updated successfully, but these errors were encountered: