juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sblackmon <sblack...@apache.org>
Subject Advice regarding Juneau RestClient, RestCall, Serializers, best practices
Date Mon, 20 Mar 2017 06:55:10 GMT
Hello,

I’m working on a class that uses RestClient to implement several contextually related methods.

Each method has a POJO describing the request, and a POJO describing the response (some methods
return a list of the response POJOs).

As I understand from reading docs for 6.1.1-incubating-SNAPSHOT, while a RestServlet may bind
multiple Serializers and Parsers, a RestClient may only bind one of each.

So i guess that means I need to instantiate a different RestClient for each supported method,
or bind a single custom Serializer and Parser that can handle all of the request and response
objects?

I notice that it’s easy to create and re-use one HttpClient across RestClients, and there’s
presumably no problem reusing all the member objects of RestClient, so there should be minimal
performance overhead to holding more than one on the class, or even creating a new RestClient
for every call is I don’t close the connection.

I also am thinking that a new method on RestClient that allowed you to doGet from an request
POJO, and have it converted into parameters (using BeanMap?) would help make this easier.

Also wondering whether type erasure will limit the flexibility of restCall.getResponse(T),
when the result comes back as a List.  In my own APIs I always return an Object but a top-level
array is fairly common practice.

Anyway, I’ve pushed some early work to this branch, and I’d be interested in feedback
as I work through this, whether it’s on the right track to minimize code complexity and
maximize performance for what we’re trying to do.

I’m not yet to the point of running any integration tests using this new implementation
but hope to be soon.

https://github.com/apache/incubator-streams/compare/master...steveblackmon:STREAMS-496

Thanks in advance,
Steve (Streams)
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message