Yes, and there are a few more implications of this (such as don't allowing users to use a custom HTTP driver).

The big problem with the DigitalOcean API is that they return a 200 OK response even when requests fail, and report the error in the body. That means that we actually need to read the body just to know if the request completed successfully. This can be done in two ways:

* Implement a response parser and annotate all API methods to parse responses using that response parser (such as the ParseJson ones). The problem here is that all error handling and retry logic provided by jclouds out of the box has already happened and ignored (because the request returned a 200 status code, see the [shouldContinue method here](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/BaseHttpCommandExecutorService.java#L149-L150).
* Use a custom HTTP driver that populates a proper response code based on the content of the body. This would allow the error and retry handlers logic to take place properly, and this is what was actually implemented here.

The trade-off of this implementation is that the body needs to be read once to determine the "correct" response status code, but then it has to be read again (if no errors were found) to deserialize the body into the corresponding domain object. As the inputstream provided by the HTTP connection may not be repeatable, we buffer the payload into that stream (which is also the default fallback of the [default http driver](https://github.com/jclouds/jclouds/blob/master/core/src/main/java/org/jclouds/http/internal/JavaUrlHttpCommandExecutorService.java#L106), to make sure we can reset it so it can be read again later, if needed.

I'd rather keep this implementation, and if at some point this is proven to generate memory issues, we can think about switching to the response parser approach (but losing the request retry and error handling logic provided by jclodus).

Do you agree?