Make Riptide async by default?

Right now we always have to maintain two APIs: Rest (sync) and AsyncRest (async). Because of Riptide’s design they both support the very same routing trees out of the box. This already makes Riptide stand out from the competition, since their APIs usually differ dramatically between the two approaches.

The problem we have right now is the different return value for async: ListenableFuture<Capture> vs. Capture. Translating from async to sync is relative easy:

http.get(..)
        .dispatch(..)
        .to(Success.class);

vs.

http.get(..)
        .dispatch(..)
        .get(10, SECONDS)
        .to(Success.class);

Given this, should we consider dropping the dedicated support for the synchronous version altogether?

[whiskeysierra]

In addition if we use Hystrix (which we really should) we already have a threadpool anyways, so that’s not a big downside.

[whiskeysierra]

but blocking calls are probably still the main usecase

They are right now, but that’s probably just caused by our mindset. If my tools would allow me to perform some request asynchronously, I’d probably do it way more often.