unirest: cross-platform REST client.
Stumbled across unirest last nite while ultimately feeling a bit unhappy with Java EE / JAX-RS frameworks. These folks in some way got my mind re-sorted a bit. I am still playing with this, yet there are a few things I already like about that one:
- It’s available. Same as some things I saw on Spark, Sinatra, Mojolicious earlier, it helps to see a REST client framework making an equal set of features and mostly the same API available for a bunch of different languages, maybe so far only missing Perl. Things-that-don’t-bind-you-too-much-to-a-particular-runtime for the win.
- At least in the Java implementation, it wraps proven libraries such as the Apache Commons HttpComponents packages and provides a more “accessible”, more straightforward API for doing the things you need in REST. Especially plain HttpClient or some of the JAX-RS client implementations tend to make you get lost in implementing loads of boilerplate code for the 80% of things you need just because all the API is built around the idea of supporting 100% in a “generic” way. At least I surely don’t want to implement a bunch of subclasses, filters, authenticators and the like just to send HTTP BASIC authentication headers. Though, at least, this seems to have grown a bit easier in recent versions of Jersey, by then it still is pretty much implementation-specific and sucks if you use JAX-RS API as this is not part of the API and so ties you to a particular JAX-RS client implementation – not what you want when explicitely using the API. Anyhow, Unirest does provide 100% of features here, but it does rather well at making the 60..80% (guessed numbers, maybe they are even smaller) of commonly used features available in a very readable, very straightforward and sane API. That’s how it possibly should be.
- Fortunately, unlike some (many?) other Java REST client frameworks, unirest doesn’t stumble the pitfall of providing yet another static (as in compile-time) xxxx-to-Java-classes mapping that tightly binds particular (JSON) properties to Java class members and makes at least parts of your code fail the very moment the wire format changes. I mean, seriously: Even each and every JSON representation will be likely to contain fields that are mandatory to your application (and, consequently, cause trouble when absent). In most of these situations, you will have to find some way how to deal with these fields being absent, so maybe it doesn’t matter whether your application will throw a custom exception or just handle an exception thrown by the JSON-to-Java mapper at the core of things; and, in case your application provider quietly and without any announcement makes substantial changes to a published API, you will need to do some talking anyway. Yet, looking at a representation such as JSON where formal validation usually doesn’t happen and most of the structures are convention rather than enforcable interface contract, maybe once again going with Postel’s Law is a good thing, so maybe there are better approaches for translating JSON representations to data structures usable in Java than compile-time mappers.
As for now, moving forth seeing where unirest takes me. So far the trip has been pretty pleasant.