问题描述
我一直在尝试实现拦截器(OkHttp 3.2&Retrofit 2)，以便在返回响应之前编辑JSON响应.我们请求数据的服务器返回不同的数据取决于成功或错误，这使映射对象变得困难.
I've been trying to implement an interceptor ( OkHttp 3.2 & Retrofit 2 ) for editing the JSON response before is returned as response. The server we request data returns different data dependes on success or error and that makes difficult to map the objects.
我试图通过将拦截器作为NetworkInterceptor添加到Retrofit中来实现，但是返回的字符串没有格式.
I was trying to do it by adding the interceptor to Retrofit as a NetworkInterceptor, however the string returned had no format.
@Override
public Response intercept(Chain chain) throws IOException {
Request request = chain.request();
Response response = chain.proceed(request);
try {
final String responseString = new String(response.body().bytes() );
LOGD("OkHttp-NET-Interceptor", "Response: " + responseString);
String newResponseString = editResponse( responseString );
LOGD("OkHttp-NET-Interceptor", "Response edited: " + newResponseString);
return response.newBuilder()
.body(ResponseBody.create(response.body().contentType(), newResponseString))
.build();
}catch (Exception ex){
return response;
}
}
responseString 的字符串没有任何可理解的格式.
responseString had a string without any understandable format.
更改为普通拦截器后，字符串的格式为a，可以将其转换为JSONObject.
After changing to the normal interceptor, the string had format a it was able to convert to JSONObject.
能否告诉我某人回复之间的区别是什么?
Could tell me someone which are the differences between the responses?
为什么这行 new String(response.body().bytes()); 返回不同的内容?
why this line new String(response.body().bytes() ); return different content?
推荐答案
名称有所不同. NetworkInterceptor连接到网络级别，是放置重试逻辑和不依赖于响应实际内容的任何内容的理想场所.
The differences are in the names. NetworkInterceptor hooks in at the network level and is an ideal place to put retry logic and anything that doesn't rely on the actual content of the response.
如果您要执行的操作取决于响应的内容(例如您的情况)，则使用ApplicationInterceptor会更有用，因为它会在您将其处理过的任何其他移动部件处理后为您提供响应，例如JSON反序列化器.否则，您将不得不在NetworkInterceptor内实现自己的反序列化JSON，考虑到Retrofit已为您完成了，这没有多大意义.
If what you do depends on the contents of the response (like in your case), using a ApplicationInterceptor is more useful, as it gives you the response after it's been processed by any other moving parts you may have such as a JSON deserializer. Otherwise you would have to implement the JSON deserializing yourself inside the NetworkInterceptor which doesn't make much sense considering it's done for you by Retrofit.
说明
Square在其Wiki上有此有用的图表，其中显示了每种拦截器的位置
Square have this useful diagram on their wiki that shows where each type of interceptor sits
因此，在ApplicationInterceptor中收到可读字符串的原因是因为Square正在尝试使两种拦截器类型的目的脱钩.他们认为您不应该在NetworkInterceptor中做出任何与应用程序有关的决定，因此，它们没有为您提供访问响应字符串的简便方法.可以了解，但就像我说的那样，他们不希望您根据响应的内容做出决定-而是希望您根据或网络状态或标头等做出决定.
Thus, the reason you receive a readable string in the ApplicationInterceptor is because Square are trying to de-couple the purposes of the two interceptor types. They don't think you should be making any application dependent decisions in the NetworkInterceptor, and so they don't provide an easy way for you to access the response string. It is possible to get ahold of, but like I said, they don't want you to make decisions that depend on the content of the response - rather, they want you to make decisions based or the network state, or headers etc.
ApplicationInterceptor是他们希望您根据响应的内容进行决策的地方，因此他们提供了更简便的方法来访问响应的内容，以便您可以做出有根据的决策以重试，或者在详细信息中他们的Wiki 重写响应(我相信这是您正在尝试的方法)来做.)
The ApplicationInterceptor is where they want you to make decisions dependent upon the contents of the response, so they provide easier methods to access the content of the response so that you can make informed decisions to retry, or as they detail in their wiki, rewrite responses (which I believe is what you're trying to do).
这篇关于Android Retrofit 2，addInterceptor和& addNetworkInterceptor用于编辑响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！