前提
返回格式是json字符串。
注：以下示例 为大致处理过程，使用的是伪代码
步骤：
1，http请求方法
用try catch包裹请求。分两次catch, 第一个catch是捕获IOException。第二个是捕获Exception异常，然后抛出非运行时异常。大致如下：
java
public string postcommon() throws IOException{
try(){
result = http.execute();//发起请求
//其他处理
}catch(IoException e){
throw e;
}catch(IoException e){
throw new IOException("Http请求处理异常",e)
}
}2，http重试处理
写个for循环，重试1中的方法3次，每次停顿500毫秒。
注意使用指数退避，防止立即发起请求，造成服务雪崩。还有sleep异常捕获的强制中断线程处理。
java
public string post() throws IOException{
final int mex=3;
final long baseDelay=500;
for(int i=1;i<=3;i++){
try{
return postcommon();
}catch (IOException e){
if(i==max){
log.error();
throw e instanceof IoException? (IOException) e:new IOException("http",e);
}
long delay=baseDelay*(long)Math.pow(2,i-1);//指数退避，设置不同的延时时间，防止立即重试挤一堆
long.warn(重新第几次，重试信息等。。)
try{
Thread.sleep(delay)
}catch (InterruptedException ie){
Thread.currentThread（）.interrupt();//需要强制中断这个异常
throw new IOException("线程被中断",ie);
}
}
}
throw new IOException(http 所有重试都失败)
}3，处理返回的json字符串
要多段异常捕获，给出不同的异常信息。
区分日志打印异常详情 和 抛出异常简介的区别
3.1 处理http请求抛出的io异常
首先捕获io异常，直接抛出外部服务异常，并异常日志。
注意是抛出自定义的异常给外层，区别日志打印日志详情。抛出的异常说明只要说明是外部服务异常即可，防止敏感信息泄露。
java
String result;
try{
result=http.post()
}catch(IOException e){
log.error(e)
throw new 自定义异常(外部服务异常码，外部服务异常)
}3.2 返回字符串转json
java
JSONObject resultObject;
try{
resultObject = JSONObject.parseObject(result);
}catch(Exception e){
log.error(请求外部接口返回结果转json异常，原始返回={}，e)
throw new 自定义异常（内部异常，请求外部接口返回结果转json异常）
}3.3 处理返回体的目标数据 并透传第三方的错误信息。
正常的请求，返回的数据会放在一个data字段中，如果data有值，则请求一定是正常的。
否则，则判断返回码是不是错误码，如是正确的，那就是返回数据就是空。
如果返回码是错误的，那就是抛出这个三方接口的异常信息，并返回。
java
JOSNObject data = resultObject.getObject("data");
if(data==null){
log.warn(外部接口返回数据为空，原始返回是={});
if(!Integer.valueOf(成功返回码).equals（ resultObject.getInteger(code1)））{
throw new CommonException(外部接口异常，resultObject.getInteger(message));
}
return Collections.empty();3.4 返回数据转成具体的java实体
到这一步就相当于请求成功了。
java
Model model = data.toJava(Model.class);
return model;4，不对外抛出异常的处理
如果调用外部接口是否异常 都不能影响我们业务主流程处理。
那么只需要在第3步的方法基础上再用try catch包一层，只打印详细的异常日志即可。
try{
handle();
}catch(Exception e){
log.warn(异常详情，e)
}
//主业务
...总结
看着很复杂，很多段的try catch。也确实很复杂。但是很必要，不同的系统对接，一旦有问题，很容易出现责任不明的问题。所以这种需求有必要详细处理。不像我们内部服务，可以模糊处理，因为都是一个人的职责。
总之 不要怕麻烦。