可以通过Web API的发送字符串被包裹在引号 [英] Strings sent through Web API's gets wrapped in quotes

问题描述

我已经与我的Web API中的ASP.NET 4的遇到了一个小问题，使用C＃。我试图创建一个GUI前端，它发送，并通过多个Web API的接收数据。之所以具有多于一个API有与我们的网络，它由几个安全区，以做。服务器被放置在不同的区域，和一个简单的请求可能必须通过多达3个不同的API。

I've run into a small problem with my Web API's in ASP.NET 4, using C#. I'm trying to create a front-end GUI which sends and receives data through multiple Web API's. The reason for having more than one API has to do with our network, which consists of several secure zones. The servers are placed in different zones, and a simple request may have to pass through as much as 3 different API's.

具体来说，我送从GUI JSON对象到第一个API。 JSON对象应该被转发至下一个API和下 - 并从那里一个新JSON对象创建并返回沿着相同的路径

Specifically, I'm sending a JSON object from the GUI to the first API. The JSON object is supposed to be forwarded to the next API and the next - and from there a new JSON object is created and returned down the same path.

路径本身工作正常。的问题是，一旦它返回到GUI JSON对象不能被解析。我收到了已经包裹在引号JSON字符串，每次一个API。

The path itself works fine. The problem is that the JSON object cannot be parsed once it returns to the GUI. I am receiving a JSON string that has been wrapped in quotes, once for each API.

该字符串可能开始时是这样的：

The string may start out like this:

嘿！我是一个字符串，或者各种各样的JSON对象！

Hey! I am a string, or a JSON object of sorts!

的API之间的第一跳给我这样的：

The first hop between API's gives me this:

嘿！我是一个字符串，或者各种各样的JSON对象！

"Hey! I am a string, or a JSON object of sorts!"

下一跳后，它看起来是这样的：

After the next hop it looks like this:

\\嘿！我是一个字符串，或者各种各样的JSON对象！\\

"\"Hey! I am a string, or a JSON object of sorts!\""

和我的GUI得到它保持的时候，我们有这样的事情：

And by the time my GUI gets hold of it we have something like this:

\\\\\\嘿！我是一个字符串，或者各种各样的JSON对象！\\\\\\

"\"\\"Hey! I am a string, or a JSON object of sorts!\\"\""

这就是解析失败，原因显而易见。 JSON对象本身是正确的格式，但所有的报价都造成了JSON.net语法上的问题（对象内的所有报价都封装多次）。

This is where parsing fails, for obvious reasons. The JSON object itself is properly formatted, but all the quotes are causing problems for the JSON.net parser (all quotes inside the object are also wrapped multiple times).

我已经试过到目前为止发送请求为应用程序/ JSON类型和text / plain的类型。无论做同样的事情。该API的返回型Htt presponseMessage，这是使用ReadAsStringAsync的read（）。我也试图避免串读，只是直接从Htt的prequestMessage只在GUI读入的Htt presponseMessage做ReadAsStringAsync（），但问题仍然存在。使用的StringContent（）方法，并投入HttpContent - 的JSON字符串使用JSON.nets序列化（）创建的。这似乎正确地做这项工作。我相信，当API和图形用户界面接收引号产生的Htt presponseMessage。

What I've tried so far is sending the request as a application/json type, and a text/plain type. Both did the same thing. The API's return a HttpResponseMessage, which are read using ReadAsStringAsync(). I've also tried to avoid the string reading and just read directly from the HttpRequestMessage into a HttpResponseMessage and do ReadAsStringAsync() only in the GUI, but the problem still remain. The JSON string is created using JSON.nets Serialize()-method, and put into the HttpContent using StringContent(). This seems to do the job correctly. I believe that the quotes are generated when the API's and the GUI receives the HttpResponseMessage.

任何想法如何，我可以发送和接收JSON字符串作为原始字符串，即不以任何方式处理？

Any idea how I can send and receive the JSON string as a raw string, that is not treated in any way?

我可以通过解析对象到JToken或JObject在每个API，并再次序列化它绕过此行为。这不是一个很好的解决方案，但是 - 我宁愿API只是转发消息正是他们得到了它的方式，而不是用它做任何事情。我看着前锋使用路由，但有很多的授权，东西怎么回事，这也要求我使用API​​行动，而不是重定向路径。

I can bypass this behaviour by parsing the object to a JToken or JObject at each API, and serializing it again. This isn't a good solution, however - I would rather the API's just forward the message exactly the way they got it, and not do anything with it. I looked into forwards using routing, but there is a lot of authorization-stuff going on, which do require that I use an API action, and not a redirect route.

要澄清（TLDR）：理想的解决方案将是API的简单地沿着消息没有经过解析或读取任何东西进去。只要消息的来源是得到授权，该请求被加密并且请求的URL是有效的，消息本身没多大关系到每一个代理的API的。

To clarify (TLDR): The ideal solution would be for the API's to simply pass along the message without parsing or reading anything into it. As long as the source of the message is authorized, the request is encrypted and the requested URL is valid, the message itself doesn't matter much to each of the "proxy" API's.

推荐答案

经过反复研究，我终于想通这一个。

After MUCH research, I finally figured this one out.

第一关;我是直接返回了Htt presponseMessage;我不是有意反序列化它沿着API路径的每一跳进去。

First off; I was returning the HttpResponseMessage directly; I was not intentionally deserializing it inside each hop along the API-path.

问题，因为事实证明，其实是我们使用的原生的MVC序列化方法和JSON.net的的搭配方法。两者本身是好的，并提供所有的API干净直通。然而，如果我们将结合来自本地方法和JSON.net的方法序列化的数据，API的进一步环比下滑将无法识别的格式，并错误地认为内容应再次序列化（使用本机方法）。

The problem, as it turns out, was actually that we were using a mix of the "native" MVC serialization methods and JSON.net's methods. Either one by itself is fine, and provides a clean passthrough of all API's. If, however, we would combine serialized data from both native methods and JSON.net-methods, the API's further down the chain would not be able to recognize the formatting and incorrectly assume that the content should be serialized again (using native methods).

因此​​，解决方案是简单地删除该序列化过程中的所有JSON.net的方法，我们结束了预期的效果。

So the solution was simply to remove all JSON.net-methods from the serialization process, and we ended up with the expected results.

这篇关于可以通过Web API的发送字符串被包裹在引号的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！