Support multiple content-types per service

[vkostyukov]

The easies solution would be to introduce a wrapper around Endpoint that captures two types - its underlying type and a content type. Something like:

val service = (
  getUsers.respond[Application.Json]
  getFoos.respond[Application.Xml]
).toService

I think we have to keep in mind that at some point we will introduce content-type member for decoder and I guess there should be a symmetric variant of respond for that.

val user = body.as[User].accept[Application.Json]

[vkostyukov]

My most recent idea is to try to attach content-type to Endpoint:

trait Endpoint[A] {
  type ContentType
}

But keep Output content-type-free. We can default to JSON for body and endpoints created with Mapper, but use text/plain for everything else (headers, params). This would allow us to reuse this type when resolving decoders. So basically having a single content-type on endpoint means we can use it in both places: when resolving encoders and decoders and this is really nice.

When composing two endpoints, the content-type will turn into a coproduct so we can expect one-by-one mapping.

Given that JSON is going to be a default, we can keep the API unchanged but mark Endpoint trait deprecated in favour explicit Endpoint.Json or even Endpoint.Aux.

[vkostyukov]

I wonder how people feel about the following syntax:

val getUsers = post[Application.Json]("users" :: body[Application.Json].as[User]) {
  Ok("users")
}

Making content-type a type member on Endpoint allows us to drop it at any point w/o any trouble (eg: we can compose :: endpoint w/o worrying of content-type of left and right sides). Although, we need to make sure it's specified at the end of the day (before applying :+:).

Not sure this is super readable though, but this is the only thing I can think of today.

[crispywalrus]

If I assume that post[Application.Json] could be :+:ed with post[Text.XML] and it could be attached to other extractors (such as body from your original sketch) then I like that. 👍

[vkostyukov]

I'm throwing this into the 0.16 milestone. The idea is to ship something similar to #583 (as an experimental API) and see if gets some adoption.