RxHttp: OkHttp with a generated layer, three concurrency models and one converter per format

The return type is chosen per call, which is the whole idea

RxHttp is an HTTP client for Android built on OkHttp, and its defining choice is that the concurrency model is decided at the call site rather than for the project. The same `RxHttp.get` can hand you an `await`, a `Flow`, an RxJava 3 `Observable` or an RxJava 2 `Observable`, because the library ships a converter for each and the annotation processor generates the glue.

The four-column table at the top of the README shows the same request written four ways. The Kotlin coroutine version ends in `.toAwait<User>().await()`, or `.awaitResult { }` for a `kotlin.Result`. The Flow version ends in `.toFlow<User>()`. The RxJava version for Kotlin uses `.toObservable<User>()`, and the one for Java takes a class literal with `.toObservable(User.class)`. The bodies are otherwise identical, which is the point: a team migrating from RxJava to coroutines can move call sites one at a time.

The feature list adds the rest of the scope. Gson, Xml, ProtoBuf and FastJson are supported for parsing. Requests close automatically when bound to a FragmentActivity, Fragment, View or ViewModel, or any other class, which removes the classic cancelled-subscription bug. Global encryption and decryption, common parameters, headers and network cache are supported, and each can be overridden per request rather than only globally.

The README states the goal as getting started in 30 seconds, and the surface area is genuinely small. What takes longer is the build setup, which is the next thing worth looking at.

The dependency comes from JitPack and needs a compiler plugin

RxHttp is published under a `com.github.liujingxing.rxhttp` coordinate, which means JitPack builds it from source, and the README's first required step is adding that repository to your build file:

allprojects {
    repositories {
        maven { url "https://jitpack.io" }
    }
}

The second required step is Java 8 or newer, configured through `compileOptions`. The third is the dependency plus the code generator, where you choose KSP or kapt and pick the matching processor artifact:

dependencies {
    def rxhttp_version = '3.5.1'
    implementation 'com.squareup.okhttp3:okhttp:4.12.0'
    implementation "com.github.liujingxing.rxhttp:rxhttp:$rxhttp_version"
    ksp "com.github.liujingxing.rxhttp:rxhttp-compiler:$rxhttp_version"
}

Note that OkHttp comes in separately and explicitly, which is the clearest statement of the architecture in the whole README: RxHttp is a layer over OkHttp, not a replacement for it, and you control which OkHttp version your app uses.

The build plugin line above the dependencies block is a detail with real consequences. It applies KSP at version 2.3.4, with a commented-out alternative for `kotlin-kapt`. KSP versions track Kotlin compiler versions, so that plugin line constrains which Kotlin version your project can use, and choosing kapt instead trades build speed for wider compatibility.

There is a supply-chain angle worth naming without dramatising it. Putting JitPack in your repositories block means your build fetches this library from a third-party service that compiles on demand rather than from Maven Central, where signed release artifacts are the norm. That is a deliberate trade many Android projects accept for access to newer libraries, and it is one you should make consciously rather than by copying a snippet.

Converters are separate artifacts you choose from six

Parsing is not built into the core artifact. Each format is an optional module, and the README lists them as a flat set of dependencies sharing the same version variable:

implementation "com.github.liujingxing.rxhttp:converter-serialization:$rxhttp_version"
implementation "com.github.liujingxing.rxhttp:converter-fastjson:$rxhttp_version"
implementation "com.github.liujingxing.rxhttp:converter-jackson:$rxhttp_version"
implementation "com.github.liujingxing.rxhttp:converter-moshi:$rxhttp_version"
implementation "com.github.liujingxing.rxhttp:converter-protobuf:$rxhttp_version"
implementation "com.github.liujingxing.rxhttp:converter-simplexml:$rxhttp_version"

Take only what you use. `converter-serialization` is the Kotlinx Serialization path, `converter-jackson` and `converter-moshi` cover Jackson and Moshi, `converter-simplexml` covers XML, `converter-protobuf` covers protocol buffers, and `converter-fastjson` is the Alibaba parser popular on Chinese Android projects.

The RxJava integration is modular in the same way. RxJava 3 needs `io.reactivex.rxjava3:rxjava` at 3.1.6 and `rxandroid` at 3.0.2, plus `com.github.liujingxing.rxlife:rxlife-rxjava3` at 2.2.2, which is the piece that provides automatic request closing. RxJava 2 has the parallel block at 2.2.8 and 2.1.1 with `rxlife-rxjava2`. So the automatic lifecycle closing is not free and not built in; it is a separate library from the same author, published under a different group id.

That dependency is worth understanding on its own, because it is a compile-time choice rather than a runtime one. The generator needs to know which RxJava major version you target and which package to generate the request classes into:

ksp {
     arg("rxhttp_rxjava", "3.1.6")
}

The README documents the equivalent for kapt and for pure Java projects using `annotationProcessorOptions`, and a second argument, `rxhttp_package`, sets the generated package, with `rxhttp.xxx` as the example. Both of these must match your project or the generated code will not compile, and the README's closing instruction for the setup section is that a rebuild is necessary.

Global setup is optional and deliberately thin

Two configuration steps are marked optional, and both are small enough to read in full.

The first is `RxHttpPlugins.init(OkHttpClient)`, which takes the OkHttp client you already built and adds a chain of setters: `setDebug(boolean)`, `setOnParamAssembly(Consumer)` and more behind an ellipsis. Passing your own OkHttp client is significant, since it means interceptors, timeouts, connection pools and TLS configuration remain yours rather than the library's.

The second is base URL configuration, and it uses an annotation on a field rather than a builder call:

public class Url {

    //Add the @defaultDomain annotation to BASE_URL
    @DefaultDomain
    public static BASE_URL = "https://..."
}

The `@DefaultDomain` annotation marks which field holds the base URL, so requests can be written with a relative path and resolved at runtime. That is what makes `RxHttp.get("/service/...")` work without repeating the host.

Per-request configuration sits on the builder chain instead. The request itself reads as a pipeline with a numbered walkthrough in the comments:

RxHttp.get("/service/...")   //1、You can choose get,postFrom,postJson etc
    .addQuery("key", "value")               //add query param
    .addHeader("headerKey", "headerValue")  //add request header
    .toObservable(Student.class)  //2、Use the toXxx method to determine the return value type, customizable
    .subscribe(student -> {  //3、Subscribing observer
        //Success callback，Default IO thread
    }, throwable -> {
        //Abnormal callback
    });

Two details there are worth internalizing. The verb selection covers `get`, `postFrom` and `postJson` among others, so body encoding is part of the request identity rather than a separate converter call. And the success callback comment says the default thread is IO, meaning RxHttp has an opinion about which scheduler you land on unless you change it.

The topic list and the dependencies disagree about what this is

The repository topics list includes `retrofit2`, and they also include `andriod`, which is a typo for android. One is a real signal and one is noise, so it is worth separating them.

Retrofit is the interesting one, because Retrofit is annotation-driven HTTP built on OkHttp, and RxHttp is also annotation-driven HTTP built on OkHttp. Having Retrofit in the topic list suggests a historical relationship or an intended association. The dependencies tell a different, clearer story: the required line is `com.squareup.okhttp3:okhttp:4.12.0`, and no Retrofit artifact appears anywhere in the install instructions. The project description also says the library is based on OkHttp encapsulation. So the tags describe an aspiration or a lineage, and the build describes the actual dependency graph.

How to judge that for yourself takes one look at what gets resolved. If you add RxHttp to a project that already uses Retrofit, check whether both appear in your dependency tree and whether they configure OkHttp independently. Two libraries each holding their own `OkHttpClient` means two connection pools and two dispatcher thread pools, which is a performance and configuration problem that will not announce itself. The optional `RxHttpPlugins.init(OkHttpClient)` API is the intended way to avoid it, by handing RxHttp the client you already have.

The `andriod` typo is the smaller of the two issues but worth mentioning because it is a reliable indicator of how the topic list was assembled. A hand-curated list would not contain it. The rest of the topics are accurate and fairly specific, covering kotlin-coroutines, okhttp3, rxjava2, rxjava3 and okhttp-rxhttp, which is a more useful set than the average.

One more structural observation. The repository contains both `README.md` and `README_zh.md`, and the English README links the Chinese one at the top rather than duplicating it, which is the right way to handle a library documented in two languages. The homepage field on the repository points to a Juejin article, which is a Chinese developer blog, so the project's own idea of its official documentation is a blog post plus the wiki rather than a documentation site.

Version numbers are clear but the changelog is not

The last three published tags are 3.5.1 on 2026-01-13, 3.5.0 on 2025-08-21 and 3.3.5 on 2025-07-23. That is a sensible maintenance rhythm with no release in the eight months since 3.5.1, and the repository's last push was on 2026-09-23, so commits have continued after the last tag. The repository is not archived.

The gap in the documentation is that those three releases carry no release notes. Their names are empty and their bodies are empty, so the changelog a maintainer would normally write is simply absent from the releases page. That matters more for a library than it would for an application, because there is no other signal about what changed.

What fills the gap is a wiki page, and the README points at it prominently, labelling it a 3.0 upgrade guide and marking it as required reading for anyone upgrading. That is a useful artefact and a narrow one: it covers the 2.x to 3.0 boundary, which is the migration most people face, and it says nothing about the patch releases since.

The dependency snippet pins `rxhttp_version` to 3.5.1, matching the newest tag, so at least the example and the release history agree. The honest way to handle the rest is to check the wiki upgrade guide before moving off 2.x, and to treat the gap between 3.3.5 and 3.5.1 as undocumented rather than assume the patch numbers are trivial. Between 3.3.5 and 3.5.0 a minor version crossed a digit, which by most versioning conventions is where behaviour changes live.

Editorial conclusion

RxHttp makes sense for an Android codebase that has both Kotlin coroutines and RxJava call sites and wants one HTTP surface across them, since the return type is a build-time choice rather than a migration. The generated converters and the automatic request closing in a lifecycle are real conveniences that you would otherwise write yourself. The costs are concrete: a build-time annotation processor or KSP step, a JitPack repository in your build file, and an upgrade story documented on a wiki rather than in release notes, since the published tags carry no changelog text. Verify first that your converter of choice has a published artifact for your RxJava version, then set `rxhttp_rxjava` and `rxhttp_package` explicitly rather than relying on defaults, and keep the 3.0 upgrade guide open during the first migration.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. liujingxing/rxhttp on GitHub
3. Project website
4. README
5. Releases