Allow request body converters to access the request body mediatype

[reda-alaoui]

Allow request body converters to access the request body mediatype

[JakeWharton]

Are you talking about the response body? The request body converter provides the media type for a request.

[reda-alaoui]

No, I am talking about the request body.
Yes, the request body converter can provide the media type for a request. But in my case, I want Retrofit to give the parsed MediaType to the request body converter.

Here is a use case:

interface MyApi {
      @POST("/foo")
      @Headers({"Content-Type: application/xml"})
      Call<Void> foo(@Body Book book);

      @POST("/bar")
      @Headers({"Content-Type: application/json"})
      Call<Void> bar(@Body Book book);
}

For a call to foo, the request body converter should serialize Book to XML.
For a call to bar, it should serialize Book to JSON.

[JakeWharton]

This way of using headers is not at all common. If you want to select different media types and converters where the type information is not sufficient to disambiguate, we recommend using custom annotations which are available to the converter factories and then having the selected converter provide the associated media type. There is a sample of this pattern here: https://github.com/square/retrofit/blob/trunk/samples%2Fsrc%2Fmain%2Fjava%2Fcom%2Fexample%2Fretrofit%2FJsonAndXmlConverters.java

[reda-alaoui]

The custom annotation would be redundant regarding built-in header annotations.

Also what should I do if somebody use the built-in header annotations in addition to my custom annotation? Notice that in this case, retrofit currently overrides the mediatype returned by the converter with the mediatype coming from header annotations. So the consumer would be able to put himself in a buggy behaviour.

Also surprised that you call uncommon telling the server that I am sending JSON using the header Content-Type.

[JakeWharton]

The custom annotation would be redundant regarding built-in header annotations.

Except specifying the content type is not the use case for method-level headers. That's the converter and RequestBody type's job.

Also what should I do if somebody use the built-in header annotations in addition to my custom annotation? Notice that in this case, retrofit currently overrides the mediatype returned by the converter with the mediatype coming from header annotations. So the consumer would be able to put himself in a buggy behaviour.

You let the server return a 4xx for sending the wrong media type. The person writing the service is responsible for setting up Retrofit correctly. I'm not sure what your role is here, are you solely an author of a converter and nothing else? As long as you return the proper media type it's not your problem if someone overrides it (which they also could do in an OkHttp interceptor).

Also surprised that you call uncommon telling the server that I am sending JSON using the header Content-Type.

What I called uncommon is providing this as method-level header instead of through the dedicated and intended mechanism as part of the RequestBody.