HttpClient does not support Get with Body in .Net 6

[trihugger]

As I having been trying to understand the design patterns for Net 6 for Authentication and Authentication, using your Blog @iammukeshm and other resources online, I noticed this issue, which seems to be worst now with Net 6. I say worst because there was two workarounds in prior versions using WebRequest/WebClient or Reflection, but all that is obsolete with .Net 6. Also, Net Core 1.x-3.x allowed it but for compitability reasons (since 4.x didn't supported it) Microsoft choose to drop support in .Net 5+.

The issue is this: When sending a request for a get (for example GetListAsync for brands or products), the web api takes it from the body.

This is perfectly fine, the problem is that with Blazor (as a client) httpclient does not allow for HttpMethod.Get with a body in the parameter. It never sends it to the API as httpclient gives this error:
"TypeError: Failed to execute 'fetch' on 'Window': Request with GET/HEAD method cannot have body."

On research it doesn't seem Microsoft is contemplating it at all: dotnet/aspnetcore#31335

The only solution I see is turning the filter into a string and receive it as a query parameter and just do Serialization/DeSerialization in the Client/Server respective. My biggest question is how does this play with other Clients like Angular and the such.

On a side note, if we were to ignore the body at all the server returns an error due to not having a body. I tried creating a FromQuery and a FromBody as nullable/default but that doesn't seem to work out of the box.

Steps to reproduce the behavior:

1. From a basic Blazor Wasm client implementation
2. Use an httpclient to sendasync with the payload (PaginationFilter) as a JsonContent/StringContent
3. Review error in Blazor

Looking for your thoughts on how to solve this either on the client side or server side.

Thank you,

Jeff

[iammukeshm]

I too faced the same dilemma recently.
Maybe just using the POST method makes more sense? as we are actually posting a JSON body to the endpoint. I currently modified the Brands Controller this way.

Now, it's a search endpoint that returns a list of BrandDto based on the applied filters. Make sense, yeah?

[iammukeshm]

and Product Search looks like this. I believe now the Client Apps wont yell :D

[trihugger]

That works, I wasn't sure if Post would create any additional issues with the return. I know one is that Get will cache server side which can add efficiency, but other than that I don't know what would be any drawn backs.

[snax4a]

Hi @trihugger, @iammukeshm,

I understand that we are using POST for the search endpoint because some libraries do not allow Body for GET requests.
Hoever I do not understand why you decided to use Body instead of query params.
Does query params have some limitations in your use cases?

I managed to successfully rewrite all pagination filters to query params but I don't know how to rewrite advancedSearch to query params as it is an object

I would like to use GET for search endpoint because POST requests are not cached and GET is more appropriate for the RESTful standard

[fretje]

You actually answer your own question. Once the object you want to send starts to get complex it's not so easy anymore to translate that to a querystring. That's the reason apparently the choice has been made to make it a post endpoint. It could become even more complex with the "AdvancedFilter" functionality that's in the pipeline. Also there's a limit on the length of an url.

[trihugger]

Just like @fretje and you mentioned, the 1024 character limitation to me is what got me concerned, but parsing complex objects would be a problem however one that could have overcome by, for example,
, enconding to base64 the json string and then decoding it back but still feels messy, and with the character limit it would make it worst since it grows your string to about 33%, and compression would be even messier.

[snax4a]

I understand, thank you