Your REST API Counterpart – part II.

Last time I listed few options how to consume services exposed by your REST backend. Some of them were rather for testing, some might be also useful for some automation (shell scripting, Jenkins/Hudson jobs, etc).

In this post, we will take another look at further choices on the client side. Please be warned, that I am not really at home in none of the demoed technologies, so the good people really using those technologies might actually want to scream. I played and tested with everything I am showing, but didn’t spend any significant amount of time with any of those.

Let’s start from A. Wait… no, we will continue up to Z– all you get today is the A.

Angular Logongular.js

We are going to pick up where we finished last time and will stick with JavaScript for a while. Angular is a remarkable front-end framework that gets lot of attention today and frankly, no surprise – it deserves it. They claim that “AngularJS is what HTML would have been, had it been designed for building web-apps. ” That looks like a good match for us.

In this case, we cannot just drop a 3 line example here showing the REST call itself – at the end of the day, it’s still just a JavaScript function encapsulating the boilerplate stuff, so that would be not interesting at all. And it would lack context. So even if the sample code may look more complex compared to jQuery example from the previous part, in projects bigger than helloworld, it will help to keep things organized and more maintainable.

Controller

Angular makes use of the concept of controllers. If you have ever worked with MVC, you know the concept. The goal is to separate the code, that controls the behaviour. the single difference is, that in this case it controls the presentation (view) behaviour only – nowadays, the view layer does not mean a static html page, it behaves somehow, so it makes sense to have a dedicated place(s) to handle it. Let’s create an (almost) empty controller:

As you can see , the controller is a JavaScript function and it is registered by calling the controller function of the module, which is again nothing more than a JavaScript function.  The first parameter is the name of the controller (for referencing the defined function from other Angular code), the second is an array consisting of global services you wish to be injected (yes, dependency injection – familiar for a Java developer, right?) as parameters of your controller (more on specific services can be found in the angular docs), and finally – as the last array member – the controller function itself.

Controller is the place all the event handlers (the onSomething() methods) according to your needs, but you can also write the code, that gets called once the component bound to the controller is created.

Backend call

In our case the code initializes the data container and stores the reference to the outer object for use in the anonymous functions. As a next step, we add a function, that loads the array of elements from the backend REST API and put it in place of the // TODO comment:

 

The method would not have any effect by itself, we only assigned the function to a local ariable, but we still need to call it. Add the following right under the previous snippet:

Displaying the result

Now the http call is really triggered (assuming that the controller is bound to some element) and the data is stored in the previously initialized container variable. But nothing more happens from the user point of view until we bind the variable to some html element.

Let’s pretend, that the fetched data is a JSON array with contacts, where every object contains the first name, last name and an e-mail. We will display it in a tabular form.

 

The snippet shows another angular concept – the directives. Those are proprietary attributes on html elements, that are discovered by the framework in order to add some functionality.

The first one of them, ng-controller, binds our controller to this element by its name and defines an alias. The second one, ng-repeat, takes care of iterating over the returned array and rendering as many <tr> elements as needed.

Now when the table element is loading, the controller is called, hence our method is called, the container variable is first initialized with empty array, but as soon as the response arrives, its updated with the JSON array. In the meantime, the empty table is already being rendered and when the stored data changes (on response), additional rows are dynamically added to the existing table.

Complicated? Not really.

Well, this looks like much more heavyweight than to use jQuery or to write the http call and response handling yourself. And it probably is. But as the requirements are getting more complex, angular helps to prevent ugly constructs in the code and badly readable workarounds. For instance, you can easily filter you result dynamically based on an input field (very responsive search in the table) and do some other tricks.

But if you are into that, you should rather read the Angular docs written by people, that really understand Angular. And as always, if you want to know more about the backend, read the Jersey docs.

Enjoy experimenting and come back to see next part some day (there are still many options how to connect to a RESTful backend), or to read about other REST related stuff.

Leave a Reply

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