retrofit之content-type浅析

背景：在做问题反馈的时候，后端是用Python写的，在post复杂的list的时候，遇到了一个坑。
向后端post结构体数组的时候，android团队版传的content-type是“text/html;charset=UTF-8”，后端同学说无法解析。按照ios那边传过来的content-type，让后端json解析这个string，这样的话，需要传递的string的格式就麻烦了，每个参数就要变成key-value的格式。

后面经过协商，后端将接口content-type统一改成“application/json; charset=utf-8”，也就是我们传过去的是一个json，好了，这下ios就有问题了，当使用json的content-type的时候，团队版后端解析不了，也就是说骑手平台app反馈这个接口需要单独使用“application/json; charset=utf-8”格式的content-type，其他所有接口，都需要使用“text/html;charset=UTF-8”。

那困扰我们android和ios的content-type到底是什么东东？

按照我的理解，content-type就是一个参数而已，我们传的什么参数，然后根据这个参数对数据做不同的处理，就跟我们使用retrofit的时候，返回response中也有content-type，根据content-type类型，决定用什么方式读取数据。

团队版发POST请求的时候，为什么content-type有时候是json，有时候是text呢？

实践发现，其实当我们在接口文件中加上@FormUrlEncoded的时候，content-type是text格式的，没有这个注解的时候，我们会传json，这是因为我们的retrofit会加上一个GsonRequestBodyConverter，这个convert将我们默认的content-type改为json。这样就是说，如果我们接口中，没有加上注解，我们会使用我们自定义好的content-type，如果有注解，我们就使用注解的content-type。

那事实是不是这样咧？我们寻找一下源码看看是不是这么一回事。

入口函数Retrofit中的create函数。

public  T create(final Class service) {
  Utils.validateServiceInterface(service);
  if (validateEagerly) {
    eagerlyValidateMethods(service);
  }
  return (T) Proxy.newProxyInstance(service.getClassLoader(), new Class[] { service },
      new InvocationHandler() {
        private final Platform platform = Platform.get();

        @Override public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
          // If the method is a method from Object then defer to normal invocation.
          if (method.getDeclaringClass() == Object.class) {
            return method.invoke(this, args);
          }
          if (platform.isDefaultMethod(method)) {
            return platform.invokeDefaultMethod(method, service, proxy, args);
          }
          ServiceMethod serviceMethod =
              (ServiceMethod) loadServiceMethod(method);
          OkHttpCall