This is an old question (2008) so there are many more options now than there were then:
UPDATES (projects still active in 2020):
- Apache HTTP Components (4.2) Fluent adapter – Basic replacement for JDK, used by several other candidates in this list. Better than old Commons HTTP Client 3 and easier to use for building your own REST client. You’ll have to use something like Jackson for JSON parsing support and you can use HTTP components URIBuilder to construct resource URIs similar to Jersey/JAX-RS Rest client. HTTP components also supports NIO but I doubt you will get better performance than BIO given the short requestnature of REST. Apache HttpComponents 5 has HTTP/2 support.
- OkHttp – Basic replacement for JDK, similar to http components, used by several other candidates in this list. Supports newer HTTP protocols (SPDY and HTTP2). Works on Android. Unfortunately it does not offer a true reactor-loop based async option (see Ning and HTTP components above). However if you use the newer HTTP2 protocol this is less of a problem (assuming connection count is problem).
- Ning Async-http-client – provides NIO support. Previously known as Async-http-client by Sonatype.
- Feign wrapper for lower level http clients (okhttp, apache httpcomponents). Auto-creates clients based on interface stubs similar to some Jersey and CXF extensions. Strong spring integration.
- Retrofit – wrapper for lower level http clients (okhttp). Auto-creates clients based on interface stubs similar to some Jersey and CXF extensions.
- Volley wrapper for jdk http client, by google
- google-http wrapper for jdk http client, or apache httpcomponents, by google
- Unirest wrapper for jdk http client, by kong
- Resteasy JakartaEE wrapper for jdk http client, by jboss, part of jboss framework
- jcabi-http wrapper for apache httpcomponents, part of jcabi collection
- restlet wrapper for apache httpcomponents, part of restlet framework
- rest-assured wrapper with asserts for easy testing
A caveat on picking HTTP/REST clients. Make sure to check what your framework stack is using for an HTTP client, how it does threading, and ideally use the same client if it offers one. That is if your using something like Vert.x or Play you may want to try to use its backing client to participate in whatever bus or reactor loop the framework provides… otherwise be prepared for possibly interesting threading issues.