Flurl icon indicating copy to clipboard operation
Flurl copied to clipboard

SetQueryParams support conversion to camelCasing

Open Davilink opened this issue 5 years ago • 7 comments

Is it possible to have the SetQueryParams() to convert to camelCase instead of using the PascalCase ?

for the mean time i use this workaroud

_userTaskClientOptions.Value.RestEndpoint
                        .AppendPathSegment("task")
                        .SetQueryParams(ToCamelCasing(query)); // Convert to camelCase

Davilink avatar Nov 19 '19 21:11 Davilink

In general I've recommended to "keep it simple" when it comes to query params. In your case, I'm not sure what type query is, but in most typical cases I think skipping the class and just using and anonymous object (whose properties are already camel-case, in your case) is usually adequate.

That said, I have gotten a fair number of requests to better control URL-encoded serialization. Doing it with attributes has been suggested, and I plan on implementing that at some point, so I'll keep this issue open - it might make sense to do it at the same time.

tmenier avatar Nov 20 '19 13:11 tmenier

Ok, thanks. The reason i'm not using a anonymous is because i query some endpoint by and HttpClient to do some query, and some parameter are allowed, an specific class restrict the potential params vs using a anonymous object.

Davilink avatar Nov 21 '19 03:11 Davilink

I second that request. It's amazing how one can simply pass in a POCO instance as an arg with Flurl. Yet there are many notational cases (snake, camel, Pascal, kebab, dots, arbitrary delimiters), and perhaps a good alternative would be to provide a set of most frequently used default serializers such as those provided in Newtonsoft's JSON.NET. In the particular case of query parameters, that's just snake, camel and Pascal.

This however has the caveat that such a transformation would be uniform across all field names. However, as is the case with JSON request/response serialization, some upstream APIs pass several versions and expose fields with different naming conventions. If Flurl could simply reuse the JSON provider attributes such as System.Text.Json.Serialization.JsonPropertyNameAttribute, for example, that would be amazing. And since Flurl maintains a dependency on JSON.NET, the reuse of Newtonsoft.Json.JsonPropertyAttribute would do the job too and maintain backward compatibility.

demming avatar Oct 07 '22 18:10 demming

I have the same issue, while trying to build a custom REST client for my API with Flurl, which has really nice features. The client is in netstandard 2.0 while my api in .netcore 6. Anyway, i use binding model classes for inputs in my API, and also use DataMember anotations for JSON serialization. The compatibility with DataContract would be a great improvement. What about generic methods, like PostJsonAsync<T>() where T is my Binding Model class with anotations, which would do the job ?

stef-studi avatar Oct 14 '22 11:10 stef-studi

Would also love this feature. I wouldn't want to 'pollute' the classes I use to pass as query string parameters with attributes, however (and I don't want to always create new anonymous objects just to change the casing).

It seems to me that casing is very similar to nullValueHandling, which is already an optional parameter; so it would be great to have a casing enumeration as an optional parameter too.

Or how about an options object, where you can specify NullValueHandling, Casing, and other things like DateFormatHandling, similar to Newtonsoft's JsonSerializerSettings?

Regarding DateFormatHandling, I notice that Newtonsoft uses the default ISO8601 formatting without any precision smaller than seconds, whereas Flurl uses Microsoft's DateTime.ToString() method with the "o" format specifier which adds 7 digits of precision after seconds. I can see why - it avoids losing precision - but in a REST context, I think the format without decimals is more common. Or ideally, Flurl could detect this: while serializing, when there's nothing to add as precision smaller than a second, then don't (and use "s" format specifier), otherwise do.

vincentsels avatar Nov 09 '22 09:11 vincentsels

Is it possible to have the SetQueryParams() to convert to camelCase instead of using the PascalCase ?

for the mean time i use this workaroud

_userTaskClientOptions.Value.RestEndpoint
                        .AppendPathSegment("task")
                        .SetQueryParams(ToCamelCasing(query)); // Convert to camelCase

@Davilink mind sharing your code for ToCamelCasing?

vincentsels avatar Nov 09 '22 09:11 vincentsels

Sadly, i don't have access to the code anymore :'(

Davilink avatar Nov 19 '22 00:11 Davilink