Enterprise components are often accessed via web resources. Some specifications clearly describe how web-based frameworks should interact with enterprise components for rendering information. However, there are other specifications that allow enterprise components (written in Java or in another language) to be accessed from non-web resources as well. Because those specifications allow for a decoupling between enterprise development and any other development, they have been defined by a number of stakeholders.
In 1998, SOAP was invented by Microsoft and subsequently used as "the" exchange format between Java applications and .Net applications. The SOAP protocol is based on XML, and the current version 1.2 became a W3C recommendation in 2003. Java provides a number of tools that allow developers to exchange data with SOAP.
Although powerful and relatively readable, SOAP is often considered to be rather verbose. With the rise of mashups and simple services offering specific functionality, a new protocol emerged: the representational state transfer (REST). The REST protocol allows server and client developers to exchange data in a loosely coupled way, where the protocol can be XML, JSON, Atom, or any other format.
SOAP
A number of Enterprise applications use SOAP at the back end, and thus require SOAP to be supported on the client as well. Fortunately, SOAP is supported in Java. The examples in this topic use the REST protocol inasmuch as this is more comprehensive, but using the javax.xml.soap package is perfectly possible in JavaFX applications, because this package is available in the Java 2 Standard Platform.
REST
The remainder of this topic is about calling REST-based web services. Plenty of resources and documentation about REST and REST-based web services can be found on the Internet. Web-based REST services expose a number of URIs (uniform resource identifiers) that can be accessed using the HTTP protocol. Typically, different HTTP request methods (get, post, put, delete) are used to indicate different operations on resources.
REST-based web services can be accessed using standard HTTP technologies, and the Java Platform comes with a number of APIs (mainly in java.io and java.net) that facilitate the access to REST-based web services.
One of the major advantages of JavaFX being written on top of the Java 2 Platform, Standard Edition is the ability to use all of these APIs in JavaFX applications. This is what we do in the first examples in this topic. We show how we can use Java APIs for consuming REST-based web services, and how we can integrate the result in a JavaFX application.
Next, we show how to leverage the JavaFX APIs to avoid common pitfalls (e.g., unresponsive applications, no dynamic update, etc.). Finally, we give a brief overview of third-party libraries that make it easy for JavaFX developers to access REST-based web services.
Setting Up the Application
First of all, we create the framework for our samples. We want to obtain tweets and render them in a JavaFX Control. For most of the samples, we use a ListView, but we also demonstrate how we can leverage the TableView APIs.
A single tweet contains information about the author (screenname, full name, picture), the timestamp, the content, and some meta-information. The goal of our samples is not to create a complete client for the Twitter API, so we only take into account a few important fields of a tweet: the name of the author, the timestamp, and the content.
Initially, we represent a tweet by a Java Object with getters and setters. This is shown in Listing 9-1.
Listing 9-1. Tweet Class
Our Tweet class has two constructors. The zero-arg constructor is needed in one of the following examples and we come back to this later. The constructor that takes three arguments is used for convenience in other examples.
In Listing 9-2, we show how to display tweets. In this first example, the tweets are not obtained via the Twitter API, but they are hard-coded in the example.
Listing 9-2. Framework for Rendering Tweets in a ListView
If you have read the previous topics, this code does not contain anything new. We create a ListView, add it to a StackPane, create a Scene, and render the Stage.
The ListView is populated with an ObservableList containing Tweets. This ObservableList is obtained by calling the getObservableList() method. In the following samples, we modify this method and show a number of ways for retrieving Tweets from the Twitter API.
■ Note The getObservableList returns an ObservableList. The ListView automatically observes this ObservableList. As a consequence, changes in the ObservableList are immediately rendered in the ListView control. In a later sample, we leverage this functionality.
Running this example results in the window shown in Figure 9-3.
Figure 9-3. The result of the first example
The resulting window contains a ListView with two entries. Those entries correspond to the two tweets that are created in the getObservableList() method at the bottom of Listing 9-2.
The information about the tweets that is shown in the window is not very useful. Indeed, we told the ListView that it should display some instances of Tweet, but we did not tell how those should be displayed. The latter can be achieved by specifying a CellFactory. In this topic, our goal is not to create a fancy user interface; rather, we want to show how to retrieve data and render these data in the user interface. Hence, we briefly show how the developer can alter the visualization of data by using the CellFactory concept.
In Listing 9-3, we create a TweetCell class that extends ListCell and that defines how to lay out a cell.
Listing 9-3. Define TweetCell
When a cell item has to be updated, we tell it to show some text containing the timestamp between square brackets, followed by the author and the content or title of the Tweet. Next, the ListView needs to be told that it should render TweetCells. We do this by calling the ListView.setCellFactory() method. In Listing 9-4, we show the modified version of the start method of our TweetApplication.
Listing 9-4. Use CellFactory on the ListView
If we now run the application, the output appears as in Figure 9-4.
Figure 9-4. The result of adding a TweetCell
For every tweet that is in the items of the ListView, the output is now what we expected it to be. We can do a lot more with CellFactories (e.g., we can use graphics instead of just text), but that is beyond the scope of this topic.
We now replace the hard-coded tweets with real information obtained via the Twitter API.
Using the Twitter API
Twitter (http://twitter.com) allows third-party developers to browse and access tweets using a REST-based interface. Twitter maintains a number of REST-based APIs, but for our examples we limit ourselves to the Search API. Detailed information on the Search API is obtained from https://dev.twitter.eom/docs/api/1/get/search or https://dev.twitter.com/docs/using-search . The resource URL—the endpoint for the REST service—is very simple:
http://search.twitter.com/search.format?q=searchterm
The search.format defines the format of the response. Currently, JSON, atom, and RSS are valid formats. Atom and RSS are both XML-based formats. The JSON (JavaScript Object Notation) format is also a human-readable text format that is very popular in REST services. In our examples, we use the JSON and the RSS format. The searchterm defines the search query. Apart from the format and the search query, there are a number of additional optional parameters that can be supplied with the request. For our examples, those two parameters are sufficient though.
If we want to retrieve tweets on "javafx" in JSON format, we call the following url.
http://search.twitter.com/search.json?q=javafx
The result is something like the JSON-text in Listing 9-5.
Listing 9-5. JSON Response Obtained from the Twitter Search API
If we would rather have the result in the XML-based RSS format, we call the following url. http://search.twitter.com/search.rss?q=javafx.
This query results in the XML response in Listing 9-6.
Listing 9-6. RSS Response Obtained from the Twitter Search API
Although the data in the JSON response contain the same information as the data in the RSS/XML response, the format is of course very different. JSON and XML are both widely used on the Internet, and a large number of web services offer responses in both formats.
Depending on the use-case and the developer, one format may be preferred over the other. In general, JavaFX applications should be able to work with both formats, because they have to connect with third-party data, and the JavaFX developer cannot always influence the data format used by the back end.
■ Note Many applications allow a number of formats, and by specifying the HTTP "Accept" Header, the client can choose between the different formats.
In the next example, we show how to retrieve and parse the JSON response used in the Twitter Search API.
