Serialize complex objects to query string

[PeterOliverDev]

Hi,

The goal of this post is to improve how it works so that we can do .SetQueryParams(object) and no matter the type of object it would work.

We wouldn't need to do .SetQueryParams(object.object).SetQueryParams(object.object2) and others manipulation for nested object.

It sometimes happens that with an HttpGet we have complex objects to pass as parameters.

We can have an object or an object in an object and this object has a list of objects.

I spent a good part of the day trying to make it work with this library, but it didn't work for me. It was always sending the namespace and class name rather than the values for my nested object.

So I started searching the internet and realized that in this StackOverFlow post, there were some interesting elements that allow you to find their properties from a class, or a list of an object. to build the query.

This is the link and my starting point was with Alvis and giorgio2 comment : https://stackoverflow.com/questions/6848296/how-do-i-serialize-an-object-into-query-string-format

Alvis has a piece of code that allows you to decipher lists of objects. giorgio2 has a piece of code which allows you to check if it is a class and if yes it recalls its function to decipher the class.

With his information, I made a prototype of my side of the code that supports objects and also object lists.

What I want to know is if people would be interested in me working on this feature.

I repeat, the goal is to no longer have to rack your brains when you want to pass parameters. We would simply have to do .SetQueryParams(object)

Thank you !

[tmenier]

This has been requested before, and there are some problems with it:

1. There's no standard or widely agreed-upon convention for how to serialize complex objects in a query string. It's entirely up to the service being called to define its required format. Some may require dot notion for sub-properties, others bracket notation, others URL-encoded JSON, to name just a few. As a client-side tool, I don't think Flurl should be in the business of favoring one approach over the others. The client's opinion doesn't matter - it's entirely up to the service you're calling.

2. Flurl currently takes the approach of simply ToStringing whatever you pass it. Some may choose to override ToString on custom classes, and if we change Flurl's serialization behavior, it'll break them.

[tmenier]

Closing this but dusting off #457 for some fresh consideration. While I stand by my reasoning for not changing the default behavior, I think making it easier to swap in other serialization strategies is probably reasonable.