通过 Web API 发送的字符串用引号括起来 [英] Strings sent through Web API's gets wrapped in quotes

问题描述

我在使用 C# 的 ASP.NET 4 中的 Web API 遇到了一个小问题.我正在尝试创建一个前端 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.

具体来说，我将一个 JSON 对象从 GUI 发送到第一个 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.

路径本身工作正常.问题是 JSON 对象一旦返回到 GUI 就无法解析.我收到一个用引号括起来的 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.

字符串可以这样开头:

嘿！我是一个字符串，或者一个 JSON 对象！

API 之间的第一跳给了我这个:

The first hop between API's gives me this:

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

在下一跳之后，它看起来像这样:

After the next hop it looks like this:

<代码>"\"嘿！我是一个字符串，或者一个 JSON 对象！\""

当我的 GUI 掌握它时，我们已经有了这样的东西:

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

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

这是解析失败的地方，原因很明显.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).

到目前为止，我尝试将请求作为 application/json 类型和 text/plain 类型发送.两者都做了同样的事情.API 返回一个 HttpResponseMessage，使用 ReadAsStringAsync() 读取.我还尝试避免读取字符串，直接从 HttpRequestMessage 读取到 HttpResponseMessage 并仅在 GUI 中执行 ReadAsStringAsync()，但问题仍然存在.JSON 字符串使用 JSON.nets Serialize() 方法创建，并使用 StringContent() 放入 HttpContent.这似乎正确地完成了这项工作.我相信引号是在 API 和 GUI 收到 HttpResponseMessage 时生成的.

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?

我可以通过在每个 API 处将对象解析为 JToken 或 JObject 并再次对其进行序列化来绕过此行为.然而，这不是一个好的解决方案——我宁愿 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.

首先;我是直接返回 HttpResponseMessage 的；我没有故意在 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-methods，我们最终得到了预期的结果.

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屋！