Your REST API Counterpart – The Client

Although JAX-RS contains client specification as its integral part, let’s assume it – it is mainly a server-side technology. The JAX-RS client can be very useful indeed – at the end of the day it was designed to work well with JAX-RS server APIs. But my guess is, that most of the times when JAX-RS client is used, it takes place on the server, for instance within a server side Jersey resource to fetch additional data from different source.

I believe that most of the time it is some other technology, that consumes data from resources exposed by Jersey. And that’s the part of the beauty of the REST architecture. You don’t have to care about it, unless you want. Of course, you can create more API versions for different devices, but you can stick with one and let anyone (who you authorise) to take advantage of it using huge variety of technologies. Let’s make a small sightseeing flight and take a look at few of the possibilities how to communicate with the REST API created with Jersey.

Example server app

For the sake of simplicity, let’s assume our server side looks like this:

 Looks funny, but I don’t want you to scroll few screens just to be more complete… I am sure your API does something more desirable.

Father curl

The classical command-line tool curl might look a bit outdated or old-school to someone, but that’s definitely not true. If you are on a system with reasonable terminal – like Linux or OS X – or use e.g. cygwin on the others, this is often the fastest way how to test, that your service. In our case (assuming the application is deployed at localhost:8080):

will return

Other methods, like POST, are still very easy:

The usefulness of curl does not end with testing, the main key feature is, that it is usable in shell script. And you can find shell everywhere, also on your Raspberry Pi and even simpler devices. The sky is the limit.

If you are lazy…

… or you just like more fruitful colours than white text on black background, there is a very nice browser extension (I use it with Chrome, but there might be versions for other browsers as well – didn’t check) called REST console.

REST Console

It’s nothing more and nothing less than a small web app (bundled as browser extension), that can hit your services based on parameters you define. Everything is clear and well-arranged, so making sure, that your REST services are exposed correctly and on the URIs you expect them to be, is a matter of seconds.

However, beside testing purposes, REST console does not have much other use cases.

Jersey Client

Although in the intro, I was promising to talk rather about other technologies than Jersey or JAX-RS client, but the list would not be complete.

Although this might look a bit bulky for a simple GET request (and note that I omitted some stuff like imports, wrapping class, etc), but as things get more complex, the client API keeps the code easy to read and consistent, while supporting basically everything you might thing of.

This is, obviously, an optimal fit for any Java environment, like a Swing app, any server-side technology such as servlets, but is also a great tool for unit testing your REST API – ideally, but not necessarily Jersey-based.

And there’s more, although it is just an experiment yet, but who knows. Jakub tested Jersey client on Android and describes it on his blog.

But there are other options on mobile devices, but let’s leave them aside for now, maybe next time.

And finally…

Of course we cannot ignore the JavaScript ecosystem. But writing the calls in pure JavaScript is rather boiler-platy and not much fun. That’s where we can make advantage of jQuery. So, how to easily incorporate REST calls to your website?

There are lot of improvements that could (and should) be done to that example, but to demonstrate the simplicity of adding AJAX to your website, it serves the purpose.

I plan to write a more in-depth post about communication with the rest API from the web front end, so this is rather to make the list more balanced, JavaScript technology may not be forgotten and jQuery is both well known and quite easy for that type of tasks. But to me, currently, Angular.js looks more tempting (you know, cool factor), so next time, I’ll probably take a look at the it as a Jersey front-end more thoroughly. And maybe also Android. And maybe something more.

Long story short – come back from time to time.


Leave a Reply

Your email address will not be published. Required fields are marked *