Loading ...
Sorry, an error occurred while loading the content.

Re: HttpClient Content-Type

Expand Messages
  • teh_benjerer
    Hi, Sorry for my long silence on this. As you suggested, I did some experimentation with this on the 0.6.x branch. I ve focused just on how to decouple the
    Message 1 of 12 , Jan 31, 2013
    • 0 Attachment
      Hi,

      Sorry for my long silence on this.

      As you suggested, I did some experimentation with this on the 0.6.x branch. I've focused just on how to decouple the request and response types of HttpClient, without affecting inference and terseness too much.

      I've stuck with Bijections for both encoding and decoding, even though they don't seem like the ideal solution; I don't want to try to change too much at once, or duplicate too much of the work that's in the master branch.

      There are two approaches I've tried.

      Firstly, I tried adding both request and response types as parameters to all the HTTP methods (HttpClient#post, etc). In many cases, where the compiler can infer both types and the appropriate Bijections correctly, this works and is quite neat.

      However there are some cases where ambiguous implicits cause a headache and it's necessary to explicitly specify both type parameters (which looks quite verbose), or to remove one or more implicits from scope. This is particularly annoying when you only want to vary one type (say, the request) but find yourself repeating the response type too, which you didn't want to change.

      Looking at my own usage of HttpClient, I find I tend to create a client instance for a particular service, which gives me a consistent response type across all of my interactions with it. So I don't need to rely on inference at the call site of get, post etc, for the response type.

      Hence, I tried removing the response type parameters from get, post etc and allowed inference only for the request encoding. This forces you to call a decode method to specify the response type you want, but works a lot more smoothly with inference and resolution of the appropriate Bijections.

      I'd greatly appreciate anyone taking a look at the changes and offering their feedback:

      https://github.com/bmjames/blueeyes/compare/jdegoes:0.6.x...bmjames:http-client-0.6.x?w=1

      Thanks,

      Ben


      --- In blueeyes-web@yahoogroups.com, "John A. De Goes" wrote:
      >
      >
      > I think it makes the most sense to put this into 0.6.x, but I'll also accept patches for 1.0. The issue with 1.0 is that much of this code will be substantially changing anyway (the odds of your change surviving intact are low).
      >
      > I'd also like to see how an experiment of your changes plays out in 0.6.x.
      > --
      > John A. De Goes
      > CEO / CTO / Founder
      > Precog - http://precog.com
      > 303.921.5784 - john@...
      > Follow us @precogio
      >
      >
      >
      >
      > On Oct 17, 2012, at 4:34 AM, teh_benjerer wrote:
      >
      > >
      > >
      > > Thanks for your replies.
      > >
      > > Are you planning to replace Bijection wholesale throughout the framework, or just the HttpClient?
      > >
      > > For me, there is a huge amount of utility in simply decoupling the request and response types, regardless of how encoding and decoding is performed.
      > >
      > > > > Did you branch off of master or the 0.6.x branch?
      > >
      > > I've branched off master. Would you rather make a 0.6.x release that is compatible with existing code using Bijections, and then try to remove the Bijection dependency entirely in the master branch?
      > >
      > > > I imagine types like this:
      > > >
      > > > decoder: A => Validation[String, B]
      > > > encoder: A => Validation[String, B]
      > >
      > > Validation is an interesting choice, can you describe how you envisage it being used? My understanding is that Validation is designed for accumulating errors in a Monoid, vs Either (or scalaz's \/) which I would use when I require fail-fast semantics. Normally if a request or response does not meet requirements I would reject it as early as possible, particularly in the case of an incoming request, as I can only return one HTTP error code.
      > >
      > > Ben
      > >
      > > --- In blueeyes-web@yahoogroups.com, Noel Welsh wrote:
      > > >
      > > > On Tue, Oct 16, 2012 at 2:30 PM, John A. De Goes wrote:
      > > >
      > > > > There are two obvious approaches:
      > > > >
      > > > > 1. Accept ordinary functions and be explicit about the conversion.
      > > > > 2. Introduce new abstractions for content encoding / decoding.
      > > > >
      > > > > Noel also has some ideas in this area. Did you branch off of master or the
      > > > > 0.6.x branch?
      > > > >
      > > >
      > > > The other major flaw with the current system is that bijections have no way
      > > > to signal failure. We have people passing us bad JSON and catching it is a
      > > > pain -- especially as we use a different error handling paradigm
      > > > (Validations) everywhere else.
      > > >
      > > > I imagine types like this:
      > > >
      > > > decoder: A => Validation[String, B]
      > > > encoder: A => Validation[String, B]
      > > >
      > > > A and B are the input and output content types (e.g. ByteChunk and
      > > > Future[JValue])
      > > >
      > > > Then you might want combinators like
      > > >
      > > > decode(decoder) etc.
      > > >
      > > > and a few convenience decodeJson etc.
      > > >
      > > > HTH,
      > > > N.
      > > >
      > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.