WCF responds with HTTP 400 to serialized JSON string from Razor Pages appRESTful web service body formatHow do I return clean JSON from a WCF Service?"Unable to read data from the transport connection: An existing connection was forcibly closed by the remote hostRender a Razor Page to stringRazor Pages - Routing from old page to new oneHow to redirect from one Razor Page to anotherDropzone on razor Page returns 400 status codeRouting to an ApiController in a razor page app?Return a partial view from a razor page HandlerPOST JSON to Razor Page returning 400Asp razor page return 400 code when POST form from Iframe
Was "The Hobbit" ever abridged?
Why do we need explainable AI?
What is the difference between "wie" and "nach" in "Klingt wie/nach..."
What drugs were used in England during the High Middle Ages?
IEEE Registration Authority mac prefix
What are the main differences in the druid class between 5th edition and 3.5 edition?
Spare the Dying during Rage Beyond Death
What's the point of this macro?
The little bee buzzes around the flower garden
Can I sleep overnight at Stansted Airport
What did Boris Johnson mean when he said "extra 34 billion going into the NHS"
How did Gollum know Sauron was gathering the Haradrim to make war?
Can a country avoid prosecution for crimes against humanity by denying it happened?
How to describe hit point damage without talking about wounds
co-son-in-law or co-brother
Why did the Joi advertisement trigger K?
Are language and thought the same?
std::tuple sizeof, is it a missed optimization?
'Hard work never hurt anyone' Why not 'hurts'?
Is the Levitate spell supposed to basically disable a melee-based enemy?
How could it be that the capo isn't changing the pitch?
First Number to Contain Each Letter
Is there a name for this metric: TN / (TN + FN)?
Does POSIX guarantee the paths to any standard utilities?
WCF responds with HTTP 400 to serialized JSON string from Razor Pages app
RESTful web service body formatHow do I return clean JSON from a WCF Service?"Unable to read data from the transport connection: An existing connection was forcibly closed by the remote hostRender a Razor Page to stringRazor Pages - Routing from old page to new oneHow to redirect from one Razor Page to anotherDropzone on razor Page returns 400 status codeRouting to an ApiController in a razor page app?Return a partial view from a razor page HandlerPOST JSON to Razor Page returning 400Asp razor page return 400 code when POST form from Iframe
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I'm trying to POST a request containing JSON from a Razor Pages app to a WCF service endpoint expecting a Json WebMessageFormat and Bare BodyStyle.The JSON passes just fine via Postman, but not when I send it through http-client. Wireshark also shows some extra bytes around JSON in the http-client produced packet that are not present in the Postman packet. Wireshark also reports this as line-based text data: application/json
for the Postman packet. The .Net packet is JavaScript Object Notation: application/json
.
Here's my C# code to send the JSON to the WCF endpoint:
var client = new HttpClient();
client.BaseAddress = new Uri("http://localhost:8000");
dynamic foo = new ExpandoObject();
foo.position = 1;
var content = new StringContent(Newtonsoft.Json.JsonConvert.SerializeObject(foo), System.Text.Encoding.UTF8, "application/json");
var request = new HttpRequestMessage(HttpMethod.Post, "http://localhost:8000/WCFService/ControllerV1/PostJSON");
request.Headers.Add("cache-control", "no-cache");
request.Headers.Add("Accept", "*/*");
request.Headers.Add("Connection", "keep-alive");
request.Content = content;
try
var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
string responseBody = await response.Content.ReadAsStringAsync();
catch (HttpRequestException e)
Console.WriteLine(e.Message);
And here's my WCF endpoint declaration:
[OperationContract, WebInvoke(Method="POST", RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]
void PostJSON(string jsonString);
I would expect the packets to produce the same response from the server, but, what appears to be the same string produces a response 200 when the packet is built by postman and a response 400 when built by .Net. I'm clearly missing something subtle here, but I can't seem to tease it out.
wcf asp.net-core dotnet-httpclient razor-pages
add a comment |
I'm trying to POST a request containing JSON from a Razor Pages app to a WCF service endpoint expecting a Json WebMessageFormat and Bare BodyStyle.The JSON passes just fine via Postman, but not when I send it through http-client. Wireshark also shows some extra bytes around JSON in the http-client produced packet that are not present in the Postman packet. Wireshark also reports this as line-based text data: application/json
for the Postman packet. The .Net packet is JavaScript Object Notation: application/json
.
Here's my C# code to send the JSON to the WCF endpoint:
var client = new HttpClient();
client.BaseAddress = new Uri("http://localhost:8000");
dynamic foo = new ExpandoObject();
foo.position = 1;
var content = new StringContent(Newtonsoft.Json.JsonConvert.SerializeObject(foo), System.Text.Encoding.UTF8, "application/json");
var request = new HttpRequestMessage(HttpMethod.Post, "http://localhost:8000/WCFService/ControllerV1/PostJSON");
request.Headers.Add("cache-control", "no-cache");
request.Headers.Add("Accept", "*/*");
request.Headers.Add("Connection", "keep-alive");
request.Content = content;
try
var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
string responseBody = await response.Content.ReadAsStringAsync();
catch (HttpRequestException e)
Console.WriteLine(e.Message);
And here's my WCF endpoint declaration:
[OperationContract, WebInvoke(Method="POST", RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]
void PostJSON(string jsonString);
I would expect the packets to produce the same response from the server, but, what appears to be the same string produces a response 200 when the packet is built by postman and a response 400 when built by .Net. I'm clearly missing something subtle here, but I can't seem to tease it out.
wcf asp.net-core dotnet-httpclient razor-pages
HttpClient doesn't even what JSON is. It simply posts a StringContent. The contents of that string are generated byJsonConvert.SerializeObject(foo)
. I suspect the real problem is the use of a WCF REST service instead of the common choice, Web API. WCF REST was a stopgap measure, quickly replaced by Web API
– Panagiotis Kanavos
Mar 28 at 11:51
There's nothing wrong with either HttpClient or Json.NET. They are used in most if not all .NET Core projects to call HTTP sevices. Json.NET is the default serializer for Web API and ASP.NET Core.
– Panagiotis Kanavos
Mar 28 at 11:56
@PanagiotisKanavos I agree that the original question seemed to indicate that I thought the fault was with http-client. I've updated both the title and the body of the question to better reflect the actual issue that I was experiencing.
– everette
Mar 29 at 15:33
add a comment |
I'm trying to POST a request containing JSON from a Razor Pages app to a WCF service endpoint expecting a Json WebMessageFormat and Bare BodyStyle.The JSON passes just fine via Postman, but not when I send it through http-client. Wireshark also shows some extra bytes around JSON in the http-client produced packet that are not present in the Postman packet. Wireshark also reports this as line-based text data: application/json
for the Postman packet. The .Net packet is JavaScript Object Notation: application/json
.
Here's my C# code to send the JSON to the WCF endpoint:
var client = new HttpClient();
client.BaseAddress = new Uri("http://localhost:8000");
dynamic foo = new ExpandoObject();
foo.position = 1;
var content = new StringContent(Newtonsoft.Json.JsonConvert.SerializeObject(foo), System.Text.Encoding.UTF8, "application/json");
var request = new HttpRequestMessage(HttpMethod.Post, "http://localhost:8000/WCFService/ControllerV1/PostJSON");
request.Headers.Add("cache-control", "no-cache");
request.Headers.Add("Accept", "*/*");
request.Headers.Add("Connection", "keep-alive");
request.Content = content;
try
var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
string responseBody = await response.Content.ReadAsStringAsync();
catch (HttpRequestException e)
Console.WriteLine(e.Message);
And here's my WCF endpoint declaration:
[OperationContract, WebInvoke(Method="POST", RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]
void PostJSON(string jsonString);
I would expect the packets to produce the same response from the server, but, what appears to be the same string produces a response 200 when the packet is built by postman and a response 400 when built by .Net. I'm clearly missing something subtle here, but I can't seem to tease it out.
wcf asp.net-core dotnet-httpclient razor-pages
I'm trying to POST a request containing JSON from a Razor Pages app to a WCF service endpoint expecting a Json WebMessageFormat and Bare BodyStyle.The JSON passes just fine via Postman, but not when I send it through http-client. Wireshark also shows some extra bytes around JSON in the http-client produced packet that are not present in the Postman packet. Wireshark also reports this as line-based text data: application/json
for the Postman packet. The .Net packet is JavaScript Object Notation: application/json
.
Here's my C# code to send the JSON to the WCF endpoint:
var client = new HttpClient();
client.BaseAddress = new Uri("http://localhost:8000");
dynamic foo = new ExpandoObject();
foo.position = 1;
var content = new StringContent(Newtonsoft.Json.JsonConvert.SerializeObject(foo), System.Text.Encoding.UTF8, "application/json");
var request = new HttpRequestMessage(HttpMethod.Post, "http://localhost:8000/WCFService/ControllerV1/PostJSON");
request.Headers.Add("cache-control", "no-cache");
request.Headers.Add("Accept", "*/*");
request.Headers.Add("Connection", "keep-alive");
request.Content = content;
try
var response = await client.SendAsync(request);
response.EnsureSuccessStatusCode();
string responseBody = await response.Content.ReadAsStringAsync();
catch (HttpRequestException e)
Console.WriteLine(e.Message);
And here's my WCF endpoint declaration:
[OperationContract, WebInvoke(Method="POST", RequestFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Bare)]
void PostJSON(string jsonString);
I would expect the packets to produce the same response from the server, but, what appears to be the same string produces a response 200 when the packet is built by postman and a response 400 when built by .Net. I'm clearly missing something subtle here, but I can't seem to tease it out.
wcf asp.net-core dotnet-httpclient razor-pages
wcf asp.net-core dotnet-httpclient razor-pages
edited Mar 29 at 15:31
everette
asked Mar 28 at 3:19
everetteeverette
257 bronze badges
257 bronze badges
HttpClient doesn't even what JSON is. It simply posts a StringContent. The contents of that string are generated byJsonConvert.SerializeObject(foo)
. I suspect the real problem is the use of a WCF REST service instead of the common choice, Web API. WCF REST was a stopgap measure, quickly replaced by Web API
– Panagiotis Kanavos
Mar 28 at 11:51
There's nothing wrong with either HttpClient or Json.NET. They are used in most if not all .NET Core projects to call HTTP sevices. Json.NET is the default serializer for Web API and ASP.NET Core.
– Panagiotis Kanavos
Mar 28 at 11:56
@PanagiotisKanavos I agree that the original question seemed to indicate that I thought the fault was with http-client. I've updated both the title and the body of the question to better reflect the actual issue that I was experiencing.
– everette
Mar 29 at 15:33
add a comment |
HttpClient doesn't even what JSON is. It simply posts a StringContent. The contents of that string are generated byJsonConvert.SerializeObject(foo)
. I suspect the real problem is the use of a WCF REST service instead of the common choice, Web API. WCF REST was a stopgap measure, quickly replaced by Web API
– Panagiotis Kanavos
Mar 28 at 11:51
There's nothing wrong with either HttpClient or Json.NET. They are used in most if not all .NET Core projects to call HTTP sevices. Json.NET is the default serializer for Web API and ASP.NET Core.
– Panagiotis Kanavos
Mar 28 at 11:56
@PanagiotisKanavos I agree that the original question seemed to indicate that I thought the fault was with http-client. I've updated both the title and the body of the question to better reflect the actual issue that I was experiencing.
– everette
Mar 29 at 15:33
HttpClient doesn't even what JSON is. It simply posts a StringContent. The contents of that string are generated by
JsonConvert.SerializeObject(foo)
. I suspect the real problem is the use of a WCF REST service instead of the common choice, Web API. WCF REST was a stopgap measure, quickly replaced by Web API– Panagiotis Kanavos
Mar 28 at 11:51
HttpClient doesn't even what JSON is. It simply posts a StringContent. The contents of that string are generated by
JsonConvert.SerializeObject(foo)
. I suspect the real problem is the use of a WCF REST service instead of the common choice, Web API. WCF REST was a stopgap measure, quickly replaced by Web API– Panagiotis Kanavos
Mar 28 at 11:51
There's nothing wrong with either HttpClient or Json.NET. They are used in most if not all .NET Core projects to call HTTP sevices. Json.NET is the default serializer for Web API and ASP.NET Core.
– Panagiotis Kanavos
Mar 28 at 11:56
There's nothing wrong with either HttpClient or Json.NET. They are used in most if not all .NET Core projects to call HTTP sevices. Json.NET is the default serializer for Web API and ASP.NET Core.
– Panagiotis Kanavos
Mar 28 at 11:56
@PanagiotisKanavos I agree that the original question seemed to indicate that I thought the fault was with http-client. I've updated both the title and the body of the question to better reflect the actual issue that I was experiencing.
– everette
Mar 29 at 15:33
@PanagiotisKanavos I agree that the original question seemed to indicate that I thought the fault was with http-client. I've updated both the title and the body of the question to better reflect the actual issue that I was experiencing.
– everette
Mar 29 at 15:33
add a comment |
1 Answer
1
active
oldest
votes
There are 2 possible BodyStyle
for request and response, wrapped or bare. When you specify wrapped body style the WCF
service expects a valid json to be passed which in your case would be
//note that property name is case sensitive and must match service parameter name
"jsonString": "some value"
And when you specify bare format the service expects only plain string value (in case of primitive type as yours) as the request like this
"some value"
When you serialize your object like this
dynamic foo = new ExpandoObject();
foo.position = 1;
string result = JsonConvert.SerializeObject(foo);
the result
contains the following json
"position":1
which corresponds to wrapped format and the service returns 400: Bad Request
. All you need to do is to turn this json into valid json string
value like this
""position":1"
It can be done by repeated JsonConvert.SerializeObject
call
dynamic foo = new ExpandoObject();
foo.position = 1;
string wrapped = JsonConvert.SerializeObject(foo);
string bare = JsonConvert.SerializeObject(wrapped);
var content = new StringContent(bare, System.Text.Encoding.UTF8, "application/json");
Thanks, that worked! I wouldn't have thought rerun the serialization. So I guess the follow up question would be whether bare or wrapped is better, but questions along those lines indicate that "it depends".
– everette
Mar 28 at 12:57
@everette Yes it depends) Bare is better because less data is sent in request, but Wrapped body is a bit more intuitive and allows us to work with valid json object as we do while working with majority of api over the internet.
– Alexander
Mar 28 at 13:04
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55389653%2fwcf-responds-with-http-400-to-serialized-json-string-from-razor-pages-app%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
There are 2 possible BodyStyle
for request and response, wrapped or bare. When you specify wrapped body style the WCF
service expects a valid json to be passed which in your case would be
//note that property name is case sensitive and must match service parameter name
"jsonString": "some value"
And when you specify bare format the service expects only plain string value (in case of primitive type as yours) as the request like this
"some value"
When you serialize your object like this
dynamic foo = new ExpandoObject();
foo.position = 1;
string result = JsonConvert.SerializeObject(foo);
the result
contains the following json
"position":1
which corresponds to wrapped format and the service returns 400: Bad Request
. All you need to do is to turn this json into valid json string
value like this
""position":1"
It can be done by repeated JsonConvert.SerializeObject
call
dynamic foo = new ExpandoObject();
foo.position = 1;
string wrapped = JsonConvert.SerializeObject(foo);
string bare = JsonConvert.SerializeObject(wrapped);
var content = new StringContent(bare, System.Text.Encoding.UTF8, "application/json");
Thanks, that worked! I wouldn't have thought rerun the serialization. So I guess the follow up question would be whether bare or wrapped is better, but questions along those lines indicate that "it depends".
– everette
Mar 28 at 12:57
@everette Yes it depends) Bare is better because less data is sent in request, but Wrapped body is a bit more intuitive and allows us to work with valid json object as we do while working with majority of api over the internet.
– Alexander
Mar 28 at 13:04
add a comment |
There are 2 possible BodyStyle
for request and response, wrapped or bare. When you specify wrapped body style the WCF
service expects a valid json to be passed which in your case would be
//note that property name is case sensitive and must match service parameter name
"jsonString": "some value"
And when you specify bare format the service expects only plain string value (in case of primitive type as yours) as the request like this
"some value"
When you serialize your object like this
dynamic foo = new ExpandoObject();
foo.position = 1;
string result = JsonConvert.SerializeObject(foo);
the result
contains the following json
"position":1
which corresponds to wrapped format and the service returns 400: Bad Request
. All you need to do is to turn this json into valid json string
value like this
""position":1"
It can be done by repeated JsonConvert.SerializeObject
call
dynamic foo = new ExpandoObject();
foo.position = 1;
string wrapped = JsonConvert.SerializeObject(foo);
string bare = JsonConvert.SerializeObject(wrapped);
var content = new StringContent(bare, System.Text.Encoding.UTF8, "application/json");
Thanks, that worked! I wouldn't have thought rerun the serialization. So I guess the follow up question would be whether bare or wrapped is better, but questions along those lines indicate that "it depends".
– everette
Mar 28 at 12:57
@everette Yes it depends) Bare is better because less data is sent in request, but Wrapped body is a bit more intuitive and allows us to work with valid json object as we do while working with majority of api over the internet.
– Alexander
Mar 28 at 13:04
add a comment |
There are 2 possible BodyStyle
for request and response, wrapped or bare. When you specify wrapped body style the WCF
service expects a valid json to be passed which in your case would be
//note that property name is case sensitive and must match service parameter name
"jsonString": "some value"
And when you specify bare format the service expects only plain string value (in case of primitive type as yours) as the request like this
"some value"
When you serialize your object like this
dynamic foo = new ExpandoObject();
foo.position = 1;
string result = JsonConvert.SerializeObject(foo);
the result
contains the following json
"position":1
which corresponds to wrapped format and the service returns 400: Bad Request
. All you need to do is to turn this json into valid json string
value like this
""position":1"
It can be done by repeated JsonConvert.SerializeObject
call
dynamic foo = new ExpandoObject();
foo.position = 1;
string wrapped = JsonConvert.SerializeObject(foo);
string bare = JsonConvert.SerializeObject(wrapped);
var content = new StringContent(bare, System.Text.Encoding.UTF8, "application/json");
There are 2 possible BodyStyle
for request and response, wrapped or bare. When you specify wrapped body style the WCF
service expects a valid json to be passed which in your case would be
//note that property name is case sensitive and must match service parameter name
"jsonString": "some value"
And when you specify bare format the service expects only plain string value (in case of primitive type as yours) as the request like this
"some value"
When you serialize your object like this
dynamic foo = new ExpandoObject();
foo.position = 1;
string result = JsonConvert.SerializeObject(foo);
the result
contains the following json
"position":1
which corresponds to wrapped format and the service returns 400: Bad Request
. All you need to do is to turn this json into valid json string
value like this
""position":1"
It can be done by repeated JsonConvert.SerializeObject
call
dynamic foo = new ExpandoObject();
foo.position = 1;
string wrapped = JsonConvert.SerializeObject(foo);
string bare = JsonConvert.SerializeObject(wrapped);
var content = new StringContent(bare, System.Text.Encoding.UTF8, "application/json");
answered Mar 28 at 11:48
AlexanderAlexander
3,8571 gold badge5 silver badges21 bronze badges
3,8571 gold badge5 silver badges21 bronze badges
Thanks, that worked! I wouldn't have thought rerun the serialization. So I guess the follow up question would be whether bare or wrapped is better, but questions along those lines indicate that "it depends".
– everette
Mar 28 at 12:57
@everette Yes it depends) Bare is better because less data is sent in request, but Wrapped body is a bit more intuitive and allows us to work with valid json object as we do while working with majority of api over the internet.
– Alexander
Mar 28 at 13:04
add a comment |
Thanks, that worked! I wouldn't have thought rerun the serialization. So I guess the follow up question would be whether bare or wrapped is better, but questions along those lines indicate that "it depends".
– everette
Mar 28 at 12:57
@everette Yes it depends) Bare is better because less data is sent in request, but Wrapped body is a bit more intuitive and allows us to work with valid json object as we do while working with majority of api over the internet.
– Alexander
Mar 28 at 13:04
Thanks, that worked! I wouldn't have thought rerun the serialization. So I guess the follow up question would be whether bare or wrapped is better, but questions along those lines indicate that "it depends".
– everette
Mar 28 at 12:57
Thanks, that worked! I wouldn't have thought rerun the serialization. So I guess the follow up question would be whether bare or wrapped is better, but questions along those lines indicate that "it depends".
– everette
Mar 28 at 12:57
@everette Yes it depends) Bare is better because less data is sent in request, but Wrapped body is a bit more intuitive and allows us to work with valid json object as we do while working with majority of api over the internet.
– Alexander
Mar 28 at 13:04
@everette Yes it depends) Bare is better because less data is sent in request, but Wrapped body is a bit more intuitive and allows us to work with valid json object as we do while working with majority of api over the internet.
– Alexander
Mar 28 at 13:04
add a comment |
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55389653%2fwcf-responds-with-http-400-to-serialized-json-string-from-razor-pages-app%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
HttpClient doesn't even what JSON is. It simply posts a StringContent. The contents of that string are generated by
JsonConvert.SerializeObject(foo)
. I suspect the real problem is the use of a WCF REST service instead of the common choice, Web API. WCF REST was a stopgap measure, quickly replaced by Web API– Panagiotis Kanavos
Mar 28 at 11:51
There's nothing wrong with either HttpClient or Json.NET. They are used in most if not all .NET Core projects to call HTTP sevices. Json.NET is the default serializer for Web API and ASP.NET Core.
– Panagiotis Kanavos
Mar 28 at 11:56
@PanagiotisKanavos I agree that the original question seemed to indicate that I thought the fault was with http-client. I've updated both the title and the body of the question to better reflect the actual issue that I was experiencing.
– everette
Mar 29 at 15:33