This tutorial shows a collection of apps that use Spring Data REST and its powerful backend functionality, combined with React’s sophisticated features to build an easy-to-understand UI.

  • Spring Data REST provides a fast way to build hypermedia-powered repositories.

  • React is Facebook’s solution to efficient, fast, and easy-to-use views in JavaScript.

Part 1 — Basic Features

Welcome, Spring community.

This section shows how to get a bare-bones Spring Data REST application up and running quickly. Then it shows how to build a simple UI on top of it by using Facebook’s React.js toolset.

Step 0 — Setting up Your Environment

Feel free to grab the code from this repository and follow along.

If you want to do it yourself, visit https://start.spring.io and pick the following dependencies:

  • Rest Repositories

  • Thymeleaf

  • JPA

  • H2

This demo uses Java 8, Maven Project, and the latest stable release of Spring Boot. It also uses React.js coded in ES6. This will give you a clean, empty project. From there, you can add the various files shown explicitly in this section and/or borrow from the repository listed earlier.

In the Beginning…​

In the beginning, there was data. And it was good. But then people wanted to access the data through various means. Over the years, people cobbled together lots of MVC controllers, many using Spring’s powerful REST support. But doing over and over cost a lot of time.

Spring Data REST addresses how simple this problem can be if some assumptions are made:

  • The developer uses a Spring Data project that supports the repository model.

  • The system uses well accepted, industry standard protocols, such as HTTP verbs, standardized media types, and IANA-approved link names.

Declaring your domain

Domain objects form the cornerstone of any Spring Data REST-based application. In this section, you will build an application to track the employees for a company. Kick that off by creating a data type, as follows:

Example 1. src/main/java/com/greglturnquist/payroll/Employee.java
@Entity (1)
public class Employee {

	private @Id @GeneratedValue Long id; (2)
	private String firstName;
	private String lastName;
	private String description;

	private Employee() {}

	public Employee(String firstName, String lastName, String description) {
		this.firstName = firstName;
		this.lastName = lastName;
		this.description = description;
	}

	@Override
	public boolean equals(Object o) {
		if (this == o) return true;
		if (o == null || getClass() != o.getClass()) return false;
		Employee employee = (Employee) o;
		return Objects.equals(id, employee.id) &&
			Objects.equals(firstName, employee.firstName) &&
			Objects.equals(lastName, employee.lastName) &&
			Objects.equals(description, employee.description);
	}

	@Override
	public int hashCode() {

		return Objects.hash(id, firstName, lastName, description);
	}

	public Long getId() {
		return id;
	}

	public void setId(Long id) {
		this.id = id;
	}

	public String getFirstName() {
		return firstName;
	}

	public void setFirstName(String firstName) {
		this.firstName = firstName;
	}

	public String getLastName() {
		return lastName;
	}

	public void setLastName(String lastName) {
		this.lastName = lastName;
	}

	public String getDescription() {
		return description;
	}

	public void setDescription(String description) {
		this.description = description;
	}

	@Override
	public String toString() {
		return "Employee{" +
			"id=" + id +
			", firstName='" + firstName + '\'' +
			", lastName='" + lastName + '\'' +
			", description='" + description + '\'' +
			'}';
	}
}
1 @Entity is a JPA annotation that denotes the whole class for storage in a relational table.
2 @Id and @GeneratedValue are JPA annotations to note the primary key and that is generated automatically when needed.

This entity is used to track employee information — in this case, their names and job descriptions.

Spring Data REST is not confined to JPA. It supports many NoSQL data stores, though you will not see those in this tutorial. For more information, see Accessing Neo4j Data with REST, Accessing JPA Data with REST, and Accessing MongoDB Data with REST.

Defining the Repository

Another key piece of a Spring Data REST application is a corresponding repository definition, as follows:

Example 2. src/main/java/com/greglturnquist/payroll/EmployeeRepository.java
public interface EmployeeRepository extends CrudRepository<Employee, Long> { (1)

}
1 The repository extends Spring Data Commons' CrudRepository and plugs in the type of the domain object and its primary key

That is all that is needed! In fact, you need not even annotate interface if it is top-level and visible. If you use your IDE and open up CrudRepository, you will find a collection of pre-defined methods.

You can define your own repository if you wish. Spring Data REST supports that as well.

Pre-loading the Demo

To work with this application, you need to pre-load it with some data, as follows:

Example 3. src/main/java/com/greglturnquist/payroll/DatabaseLoader.java
@Component (1)
public class DatabaseLoader implements CommandLineRunner { (2)

	private final EmployeeRepository repository;

	@Autowired (3)
	public DatabaseLoader(EmployeeRepository repository) {
		this.repository = repository;
	}

	@Override
	public void run(String... strings) throws Exception { (4)
		this.repository.save(new Employee("Frodo", "Baggins", "ring bearer"));
	}
}
1 This class is marked with Spring’s @Component annotation so that it is automatically picked up by @SpringBootApplication.
2 It implements Spring Boot’s CommandLineRunner so that it gets run after all the beans are created and registered.
3 It uses constructor injection and autowiring to get Spring Data’s automatically created EmployeeRepository.
4 The run() method is invoked with command line arguments, loading up your data.

One of the biggest, most powerful features of Spring Data is its ability to write JPA queries for you. This not only cuts down on your development time, but it also reduces the risk of bugs and errors. Spring Data looks at the name of methods in a repository class and figures out the operations you need, including saving, deleting, and finding.

That is how we can write an empty interface and inherit already built save, find, and delete operations.

Adjusting the Root URI

By default, Spring Data REST hosts a root collection of links at /. Because you will host a web UI on that path, you need to change the root URI, as follows:

Example 4. src/main/resources/application.properties
spring.data.rest.base-path=/api

Launching the Backend

The last step needed to get a fully operational REST API off the ground is to write a public static void main method by using Spring Boot, as follows:

Example 5. src/main/java/com/greglturnquist/payroll/ReactAndSpringDataRestApplication.java
@SpringBootApplication
public class ReactAndSpringDataRestApplication {

	public static void main(String[] args) {
		SpringApplication.run(ReactAndSpringDataRestApplication.class, args);
	}
}

Assuming the previous class as well as your Maven build file were generated from https://start.spring.io, you can now launch it either by running that main() method inside your IDE or by typing ./mvnw spring-boot:run on the command line. (mvnw.bat for Windows users).

If you are not up-to-date on Spring Boot and how it works, you should watch one of Josh Long’s introductory presentations. Did it? Press on!

Touring Your REST Service

With the application running, you can check things out on the command line by using cURL (or any other tool you like). The following command (shown with its output) lists the links in the application:

$ curl localhost:8080/api
{
  "_links" : {
    "employees" : {
      "href" : "http://localhost:8080/api/employees"
    },
    "profile" : {
      "href" : "http://localhost:8080/api/profile"
    }
  }
}

When you ping the root node, you get back a collection of links wrapped in a HAL-formatted JSON document.

  • _links is the collection of available links.

  • employees points to an aggregate root for the employee objects defined by the EmployeeRepository interface.

  • profile is an IANA-standard relation and points to discoverable metadata about the entire service. We explore this in a later section.

You can further dig into this service by navigating the employees link. The following command (shown with its output) does so:

$ curl localhost:8080/api/employees
{
  "_embedded" : {
    "employees" : [ {
      "firstName" : "Frodo",
      "lastName" : "Baggins",
      "description" : "ring bearer",
      "_links" : {
        "self" : {
          "href" : "http://localhost:8080/api/employees/1"
        }
      }
    } ]
  }
}

At this stage, you are viewing the entire collection of employees.

Along with the data you pre-loaded earlier, a _links attribute with a self link is included. This is the canonical link for that particular employee. What is canonical? It means “free of context”. For example, the same user could be fetched through /api/orders/1/processor, in which the employee is associated with processing a particular order. Here, there is no relationship to other entities.

Links are a critical facet of REST. They provide the power to navigate to related items. It makes it possible for other parties to navigate around your API without having to rewrite things every time there is a change. Updates in the client is a common problem when the clients hard-code paths to resources. Restructuring resources can cause big upheavals in code. If links are used and the navigation route is maintained, it becomes easy and flexible to make such adjustments.

You can decide to view that one employee if you wish. The following command (shown with its output) does so:

$ curl localhost:8080/api/employees/1
{
  "firstName" : "Frodo",
  "lastName" : "Baggins",
  "description" : "ring bearer",
  "_links" : {
    "self" : {
      "href" : "http://localhost:8080/api/employees/1"
    }
  }
}

Little has changed here, except that there is no need for the _embedded wrapper since there is only the domain object.

That is all well and good, but you are probably itching to create some new entries. The following command (shown with its output) does so:

$ curl -X POST localhost:8080/api/employees -d "{\"firstName\": \"Bilbo\", \"lastName\": \"Baggins\", \"description\": \"burglar\"}" -H "Content-Type:application/json"
{
  "firstName" : "Bilbo",
  "lastName" : "Baggins",
  "description" : "burglar",
  "_links" : {
    "self" : {
      "href" : "http://localhost:8080/api/employees/2"
    }
  }
}

You can also PUT, PATCH, and DELETE, as shown in this related guide. For now, though, we will move on to building a slick UI.

Setting up a Custom UI Controller

Spring Boot makes it super simple to stand up a custom web page. First, you need a Spring MVC controller, as follows:

Example 6. src/main/java/com/greglturnquist/payroll/HomeController.java
@Controller (1)
public class HomeController {

	@RequestMapping(value = "/") (2)
	public String index() {
		return "index"; (3)
	}

}
1 @Controller marks this class as a Spring MVC controller.
2 @RequestMapping flags the index() method to support the / route.
3 It returns index as the name of the template, which Spring Boot’s autoconfigured view resolver will map to src/main/resources/templates/index.html.

Defining an HTML template

You are using Thymeleaf, although you will not really use many of its features. To get started you need an index page, as follows:

Example 7. src/main/resources/templates/index.html
<!DOCTYPE html>
<html xmlns:th="https://www.thymeleaf.org">
<head lang="en">
    <meta charset="UTF-8"/>
    <title>ReactJS + Spring Data REST</title>
    <link rel="stylesheet" href="/main.css" />
</head>
<body>

    <div id="react"></div>

    <script src="built/bundle.js"></script>

</body>
</html>

The key part in this template is the <div id="react"></div> component in the middle. It is where you will direct React to plug in the rendered output.

You may also wonder where that bundle.js file came from. The way it is built is shown in the next section.

This tutorial does not show main.css, but you can see it linked up above. When it comes to CSS, Spring Boot will automatically serve anything found in src/main/resources/static. Put your own main.css file there. It is not shown in the tutorial, since our focus is on React and Spring Data REST, not CSS.

Loading JavaScript Modules

This section contains the barebones information to get the JavaScript bits off the ground. While you can install all of JavaScripts command line tools, you need not do so — at least, not yet. Instead, all you need to do is add the following to your pom.xml build file:

Example 8. The frontend-maven-plugin used to build JavaScript bits
<plugin>
	<groupId>com.github.eirslett</groupId>
	<artifactId>frontend-maven-plugin</artifactId>
</plugin>

This little plugin perform multiple steps:

  • The install-node-and-npm command will install node.js and its package management tool, npm, into the target folder. (This ensures the binaries are NOT pulled under source control and can be cleaned out with clean).

  • The npm command will execute the npm binary with the provided argument (install). This installs the modules defined in package.json.

  • The webpack command will execute webpack binary, which compiles all the JavaScript code based on webpack.config.js.

These steps are run in sequence, essentially installing node.js, downloading JavaScript modules, and building the JS bits.

What modules are installed? JavaScript developers typically use npm to build up a package.json file, such as the following:

Example 9. package.json
{
  "name": "spring-data-rest-and-reactjs",
  "version": "0.1.0",
  "description": "Demo of ReactJS + Spring Data REST",
  "repository": {
    "type": "git",
    "url": "[email protected]:spring-guides/tut-react-and-spring-data-rest.git"
  },
  "keywords": [
    "rest",
    "hateoas",
    "spring",
    "data",
    "react"
  ],
  "author": "Greg L. Turnquist",
  "license": "Apache-2.0",
  "bugs": {
    "url": "https://github.com/spring-guides/tut-react-and-spring-data-rest/issues"
  },
  "homepage": "https://github.com/spring-guides/tut-react-and-spring-data-rest",
  "dependencies": {
    "react": "^16.5.2",
    "react-dom": "^16.5.2",
    "rest": "^1.3.1"
  },
  "scripts": {
    "watch": "webpack --watch -d --output ./target/classes/static/built/bundle.js"
  },
  "devDependencies": {
    "@babel/core": "^7.1.0",
    "@babel/preset-env": "^7.1.0",
    "@babel/preset-react": "^7.0.0",
    "babel-loader": "^8.0.2",
    "webpack": "^4.19.1",
    "webpack-cli": "^3.1.0"
  }
}

Key dependencies include:

  • react.js: The toolkit used by this tutorial

  • rest.js: CujoJS toolkit used to make REST calls

  • webpack: A toolkit used to compile JavaScript components into a single, loadable bundle

  • babel: To write your JavaScript code using ES6 and compile it into ES5 to run in the browser

To build the JavaScript code you’ll use later, you need to define a build file for webpack, as follows:

Example 10. webpack.config.js
var path = require('path');

module.exports = {
    entry: './src/main/js/app.js',
    devtool: 'sourcemaps',
    cache: true,
    mode: 'development',
    output: {
        path: __dirname,
        filename: './src/main/resources/static/built/bundle.js'
    },
    module: {
        rules: [
            {
                test: path.join(__dirname, '.'),
                exclude: /(node_modules)/,
                use: [{
                    loader: 'babel-loader',
                    options: {
                        presets: ["@babel/preset-env", "@babel/preset-react"]
                    }
                }]
            }
        ]
    }
};

This webpack configuration file:

  • Defines the entry point as ./src/main/js/app.js. In essence, app.js (a module you will write shortly) is the proverbial public static void main() of our JavaScript application. webpack must know this in order to know what to launch when the final bundle is loaded by the browser.

  • Creates sourcemaps so that, when you are debugging JS code in the browser, you can link back to original source code.

  • Compile ALL of the JavaScript bits into ./src/main/resources/static/built/bundle.js, which is a JavaScript equivalent to a Spring Boot uber JAR. All your custom code AND the modules pulled in by the require() calls are stuffed into this file.

  • It hooks into the babel engine, using both es2015 and react presets, in order to compile ES6 React code into a format able to be run in any standard browser.

For more details on how each of these JavaScript tools operates, please read their corresponding reference docs.

Want to see your JavaScript changes automatically? Run npm run-script watch to put webpack into watch mode. It will regenerate bundle.js as you edit the source.

With all that in place, you can focus on the React bits, which are fetched after the DOM is loaded. It is broken down into parts, as follows:

Since you are using webpack to assemble things, go ahead and fetch the modules you need:

Example 11. src/main/js/app.js
const React = require('react'); (1)
const ReactDOM = require('react-dom'); (2)
const client = require('./client'); (3)
1 React is one of the main libraries from Facebook used to build this app.
2 ReactDOM is the package that serves as the entry point to the DOM and server renderers for React. It is intended to be paired with the generic React package.
3 client is custom code that configures rest.js to include support for HAL, URI Templates, and other things. It also sets the default Accept request header to application/hal+json. You can read the code here.
The code for client is not shown because what you use to make REST calls is not important. Feel free to check the source, but the point is, you can plugin Restangular (or anything you like), and the concepts still apply.

Diving into React

React is based on defining components. Often, one component can hold multiple instances of another in a parent-child relationship. This concept can extend to several layers.

To start things off, it is very handy to have a top level container for all components. (This will become more evident as you expand upon the code throughout this series.) Right now, you only have the employee list. But you might need some other related components later on, so start with the following:

Example 12. src/main/js/app.js - App component
class App extends React.Component { (1)

	constructor(props) {
		super(props);
		this.state = {employees: []};
	}

	componentDidMount() { (2)
		client({method: 'GET', path: '/api/employees'}).done(response => {
			this.setState({employees: response.entity._embedded.employees});
		});
	}

	render() { (3)
		return (
			<EmployeeList employees={this.state.employees}/>
		)
	}
}
1 class App extends React.Component{…​} is the method that creates a React component.
2 componentDidMount is the API invoked after React renders a component in the DOM.
3 render is the API that “draws” the component on the screen.
In React, uppercase is the convention for naming components.

In the App component, an array of employees is fetched from the Spring Data REST backend and stored in this component’s state data.

React components have two types of data: state and properties.

State is data that the component is expected to handle itself. It is also data that can fluctuate and change. To read the state, you use this.state. To update it, you use this.setState(). Every time this.setState() is called, React updates the state, calculates a diff between the previous state and the new state, and injects a set of changes to the DOM on the page. This results in fast and efficient updates to your UI.

The common convention is to initialize state with all your attributes empty in the constructor. Then you look up data from the server by using componentDidMount and populating your attributes. From there on, updates can be driven by user action or other events.

Properties encompass data that is passed into the component. Properties do NOT change but are instead fixed values. To set them, you assign them to attributes when creating a new component, as you will soon see.

JavaScript does not lock down data structures as other languages do. You can try to subvert properties by assigning values, but this does not work with React’s differential engine and should be avoided.

In this code, the function loads data through client, a Promise-compliant instance of rest.js. When it is done retrieving from /api/employees, it then invokes the function inside done() and sets the state based on its HAL document (response.entity._embedded.employees). See the structure of curl /api/employees earlier and see how it maps onto this structure.

When the state is updated, the render() function is invoked by the framework. The employee state data is included in the creation of the <EmployeeList /> React component as an input parameter.

The following listing shows the definition for an EmployeeList:

Example 13. src/main/js/app.js - EmployeeList component
class EmployeeList extends React.Component{
	render() {
		const employees = this.props.employees.map(employee =>
			<Employee key={employee._links.self.href} employee={employee}/>
		);
		return (
			<table>
				<tbody>
					<tr>
						<th>First Name</th>
						<th>Last Name</th>
						<th>Description</th>
					</tr>
					{employees}
				</tbody>
			</table>
		)
	}
}

Using JavaScript’s map function, this.props.employees is transformed from an array of employee records into an array of <Element /> React components (which you will see a little later).

Consider the following listing:

<Employee key={employee._links.self.href} data={employee} />

The preceding listing creates a new React component (note the uppercase format) with two properties: key and data. These are supplied with values from employee._links.self.href and employee.

Whenever you work with Spring Data REST, the self link is the key for a given resource. React needs a unique identifier for child nodes, and _links.self.href is perfect.

Finally, you return an HTML table wrapped around the array of employees built with mapping, as follows:

<table>
    <tr>
        <th>First Name</th>
        <th>Last Name</th>
        <th>Description</th>
    </tr>
    {employees}
</table>

This simple layout of state, properties, and HTML shows how React lets you declaratively create a simple and easy-to-understand component.

Does this code contain both HTML and JavaScript? Yes, this is JSX. There is no requirement to use it. React can be written using pure JavaScript, but the JSX syntax is quite terse. Thanks to rapid work on the Babel.js, the transpiler provides both JSX and ES6 support all at once.

JSX also includes bits and pieces of ES6. The one used in this code is the arrow function. It avoids creating a nested function() with its own scoped this and avoids needing a self variable.

Worried about mixing logic with your structure? React’s APIs encourage nice, declarative structure combined with state and properties. Instead of mixing a bunch of unrelated JavaScript and HTML, React encourages building simple components with small bits of related state and properties that work well together. It lets you look at a single component and understand the design. Then they are easy to combine together for bigger structures.

Next, you need to actually define what an <Employee /> is, as follows:

Example 14. src/main/js/app.js - Employee component
class Employee extends React.Component{
	render() {
		return (
			<tr>
				<td>{this.props.employee.firstName}</td>
				<td>{this.props.employee.lastName}</td>
				<td>{this.props.employee.description}</td>
			</tr>
		)
	}
}

This component is very simple. It has a single HTML table row wrapped around the employee’s three properties. The property itself is this.props.employee. Notice how passing in a JavaScript object makes it easy to pass along data fetched from the server.

Because this component does not manage any state nor deal with user input, there is nothing else to do. This might tempt you to cram it into the <EmployeeList /> up above. Do not do it! Splitting your app up into small components that each do one job will make it easier to build up functionality in the future.

The last step is to render the whole thing, as follows:

Example 15. src/main/js/app.js - rendering code
ReactDOM.render(
	<App />,
	document.getElementById('react')
)

React.render() accepts two arguments: a React component you defined as well as a DOM node to inject it into. Remember how you saw the <div id="react"></div> item earlier from the HTML page? This is where it gets picked up and plugged in.

With all this in place, re-run the application (./mvnw spring-boot:run) and visit http://localhost:8080. The following image shows the updated application:

basic 1

You can see the initial employee loaded up by the system.

Remember using cURL to create new entries? Do that again with the following command:

curl -X POST localhost:8080/api/employees -d "{\"firstName\": \"Bilbo\", \"lastName\": \"Baggins\", \"description\": \"burglar\"}" -H "Content-Type:application/json"

Refresh the browser, and you should see the new entry:

basic 2

Now you can see both of them listed on the web site.

Review

In this section:

  • You defined a domain object and a corresponding repository.

  • You let Spring Data REST export it with full-blown hypermedia controls.

  • You created two simple React components in a parent-child relationship.

  • You fetched server data and rendered them in as a simple, static HTML structure.

Issues?

  • The web page was not dynamic. You had to refresh the browser to fetch new records.

  • The web page did not use any hypermedia controls or metadata. Instead, it was hardcoded to fetch data from /api/employees.

  • It is read only. While you can alter records using cURL, the web page offers no interactivity.

We address these shortcomings in the next section.

Part 2 - Hypermedia Controls

In the previous section, you found out how to create a backend payroll service to store employee data by using Spring Data REST. A key feature it lacked was using the hypermedia controls and navigation by links. Instead, it hard-coded the path to find data.

Feel free to grab the code from this repository and follow along. This section is based on the previous section’s application, with extra things added.

In the Beginning, There Was Data…​and Then There Was REST

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC…​.What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?
— Roy T. Fielding
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

So, what exactly ARE hypermedia controls (that is, hypertext) and how can you use them? To find out, we take a step back and look at the core mission of REST.

The concept of REST was to borrow ideas that made the web so successful and apply them to APIs. Despite the web’s vast size, dynamic nature, and low rate at which clients (that is, browsers) are updated, the web is an amazing success. Roy Fielding sought to use some of its constraints and features and see if that would afford similar expansion of API production and consumption.

One of the constraints is to limit the number of verbs. For REST, the primary ones are GET, POST, PUT, DELETE, and PATCH. There are others, but we will not get into them here.

  • GET: Fetches the state of a resource without altering the system

  • POST: Creates a new resource without saying where

  • PUT: Replaces an existing resource, overwriting whatever else (if anything) is already there

  • DELETE: Removes an existing resource

  • PATCH: Alters an existing resource (partially rather than creating a new resource)

These are standardized HTTP verbs with well known specifications. By picking up and using already coined HTTP operations, we need not invent a new language and educate the industry.

Another constraint of REST is to use media types to define the format of data. Instead of everyone writing their own dialect for the exchange of information, it would be prudent to develop some media types. One of the most popular ones to be accepted is HAL, media type application/hal+json. It is Spring Data REST’s default media type. A key value is that there is no centralized, single media type for REST. Instead, people can develop media types and plug them in and try them out. As different needs become available, the industry can flexibly move.

A key feature of REST is to include links to relevant resources. For example, if you were looking at an order, a RESTful API would include a link to the related customer, links to the catalog of items, and perhaps a link to the store from which the order was placed. In this section, you will introduce paging and see how to also use navigational paging links.

Turning on Paging from the Backend

To get underway with using frontend hypermedia controls, you need to turn on some extra controls. Spring Data REST provides paging support. To use it, tweak the repository definition as follows:

Example 16. src/main/java/com/greglturnquist/payroll/EmployeeRepository.java
public interface EmployeeRepository extends PagingAndSortingRepository<Employee, Long> {

}

Your interface now extends PagingAndSortingRepository, which adds extra options to set page size and adds navigational links to hop from page to page. The rest of the backend is the same (except for some extra pre-loaded data to make things interesting).

Restart the application (./mvnw spring-boot:run) and see how it works. Then run the following command (shown with its output) to see the paging in action:

$ curl "localhost:8080/api/employees?size=2"
{
  "_links" : {
    "first" : {
      "href" : "http://localhost:8080/api/employees?page=0&size=2"
    },
    "self" : {
      "href" : "http://localhost:8080/api/employees"
    },
    "next" : {
      "href" : "http://localhost:8080/api/employees?page=1&size=2"
    },
    "last" : {
      "href" : "http://localhost:8080/api/employees?page=2&size=2"
    }
  },
  "_embedded" : {
    "employees" : [ {
      "firstName" : "Frodo",
      "lastName" : "Baggins",
      "description" : "ring bearer",
      "_links" : {
        "self" : {
          "href" : "http://localhost:8080/api/employees/1"
        }
      }
    }, {
      "firstName" : "Bilbo",
      "lastName" : "Baggins",
      "description" : "burglar",
      "_links" : {
        "self" : {
          "href" : "http://localhost:8080/api/employees/2"
        }
      }
    } ]
  },
  "page" : {
    "size" : 2,
    "totalElements" : 6,
    "totalPages" : 3,
    "number" : 0
  }
}

The default page size is 20, but we do not have that much data. So, to see it in action, we set ?size=2. As expected, only two employees are listed. In addition, there are also first, next, and last links. There is also the self link, which is free of context, including page parameters.

If you navigate to the next link, you’ll see a prev link as well. The following command (shown with its output) does so:

$ curl "http://localhost:8080/api/employees?page=1&size=2"
{
  "_links" : {
    "first" : {
      "href" : "http://localhost:8080/api/employees?page=0&size=2"
    },
    "prev" : {
      "href" : "http://localhost:8080/api/employees?page=0&size=2"
    },
    "self" : {
      "href" : "http://localhost:8080/api/employees"
    },
    "next" : {
      "href" : "http://localhost:8080/api/employees?page=2&size=2"
    },
    "last" : {
      "href" : "http://localhost:8080/api/employees?page=2&size=2"
    }
  },
...
When using & in URL query parameters, the command line thinks it is a line break. Wrap the whole URL with quotation marks to avoid that problem.

That looks neat, but it will be even better when you update the frontend to take advantage of it.

Navigating by Relationship

No more changes are needed on the backend to start using the hypermedia controls Spring Data REST provides out of the box. You can switch to working on the frontend. (That is part of the beauty of Spring Data REST: No messy controller updates!)

It is important to point out that this application is not “Spring Data REST-specific.” Instead, it uses HAL, URI Templates, and other standards. That is why using rest.js is a snap: That library comes with HAL support.

In the previous section, you hardcoded the path to /api/employees. Instead, the ONLY path you should hardcode is the root, as follows

...
var root = '/api';
...

With a handy little follow() function, you can now start from the root and navigate to where you want, as follows:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=follow-1]

In the previous section, the loading was done directly inside componentDidMount(). In this section, we are making it possible to reload the entire list of employees when the page size is updated. To do so, we have moved things into loadFromServer(), as follows:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=follow-2]

loadFromServer is very similar to the previous section. However, it uses follow():

  • The first argument to the follow() function is the client object used to make REST calls.

  • The second argument is the root URI to start from.

  • The third argument is an array of relationships to navigate along. Each one can be a string or an object.

The array of relationships can be as simple as ["employees"], meaning when the first call is made, look in _links for the relationship (or rel) named employees. Find its href and navigate to it. If there is another relationship in the array, repeat the process.

Sometimes, a rel by itself is not enough. In this fragment of code, it also plugs in a query parameter of ?size=<pageSize>. There are other options that can be supplied, as you will see later.

Grabbing JSON Schema Metadata

After navigating to employees with the size-based query, the employeeCollection is available. In the previous section, we displayed that data inside <EmployeeList />. In this section, you are performing another call to grab some JSON Schema metadata found at /api/profile/employees/.

You can see the data yourself by running the following curl command (shown with its output):

$ curl http://localhost:8080/api/profile/employees -H "Accept:application/schema+json"
{
  "title" : "Employee",
  "properties" : {
    "firstName" : {
      "title" : "First name",
      "readOnly" : false,
      "type" : "string"
    },
    "lastName" : {
      "title" : "Last name",
      "readOnly" : false,
      "type" : "string"
    },
    "description" : {
      "title" : "Description",
      "readOnly" : false,
      "type" : "string"
    }
  },
  "definitions" : { },
  "type" : "object",
  "$schema" : "https://json-schema.org/draft-04/schema#"
}
The default form of metadata at /profile/employees is ALPS. In this case, though, you are using content negotiation to fetch JSON Schema.

By capturing this information in the`<App />` component’s state, you can make good use of it later when building input forms.

Creating New Records

Equipped with this metadata, you can now add some extra controls to the UI. You can start by creating a new React component <CreateDialog />, as follows:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=create-dialog]

This new component has both a handleSubmit() function and the expected render() function.

We dig into these functions in reverse order, looking first at the render() function.

Rendering

Your code maps over the JSON Schema data found in the attributes property and converts it into an array of <p><input></p> elements.

  • key is again needed by React to distinguish between multiple child nodes.

  • It is a simple text-based entry field.

  • placeholder lets us show the user with field is which.

  • You may be used to having a name attribute, but it is not necessary. With React, ref is the mechanism for grabbing a particular DOM node (as you will soon see).

This represents the dynamic nature of the component, driven by loading data from the server.

Inside this component’s top-level <div> is an anchor tag and another <div>. The anchor tag is the button to open the dialog. And the nested <div> is the hidden dialog itself. In this example, you are using pure HTML5 and CSS3. No JavaScript at all! You can see the CSS code used to show and hide the dialog. We will not dive into that here.

Nestled inside <div id="createEmployee"> is a form where your dynamic list of input fields are injected followed by the Create button. That button has an onClick={this.handleSubmit} event handler. This is the React way of registering an event handler.

React does not create event handlers on every DOM element. Instead, it has a much more performant and sophisticated solution. You need not manage that infrastructure and can instead focus on writing functional code.

Handling User Input

The handleSubmit() function first stops the event from bubbling further up the hierarchy. It then uses the same JSON Schema attribute property to find each <input>, by using React.findDOMNode(this.refs[attribute]).

this.refs is a way to reach out and grab a particular React component by name. Note that you are getting ONLY the virtual DOM component. To grab the actual DOM element, you need to use React.findDOMNode().

After iterating over every input and building up the newEmployee object, we invoke a callback to onCreate() for the new employee record. This function is inside App.onCreate and was provided to this React component as another property. Look at how that top-level function operates:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=create]

Once again, we use the follow() function to navigate to the employees resource where POST operations are performed. In this case, there was no need to apply any parameters, so the string-based array of rel instance is fine. In this situation, the POST call is returned. This allows the next then() clause to handle processing the outcome of the POST.

New records are typically added to the end of the dataset. Since you are looking at a certain page, it is logical to expect the new employee record to not be on the current page. To handle this, you need to fetch a new batch of data with the same page size applied. That promise is returned for the final clause inside done().

Since the user probably wants to see the newly created employee, you can then use the hypermedia controls and navigate to the last entry.

First time using a promise-based API? Promises are a way to kick off asynchronous operations and then register a function to respond when the task is done. Promises are designed to be chained together to avoid “callback hell”. Look at the following flow:

when.promise(async_func_call())
	.then(function(results) {
		/* process the outcome of async_func_call */
	})
	.then(function(more_results) {
		/* process the previous then() return value */
	})
	.done(function(yet_more) {
		/* process the previous then() and wrap things up */
	});

For more details, check out this tutorial on promises.

The secret thing to remember with promises is that then() functions need to return something, whether it is a value or another promise. done() functions do NOT return anything, and you do not chain anything after one. In case you have not yet noticed, client (which is an instance of rest from rest.js) and the follow function return promises.

Paging Through Data

You have set up paging on the backend and have already starting taking advantage of it when creating new employees.

In the previous section, you used the page controls to jump to the last page. It would be really handy to dynamically apply it to the UI and let the user navigate as desired. Adjusting the controls dynamically, based on available navigation links, would be great.

First, let’s check out the onNavigate() function you used:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=navigate]

This is defined at the top, inside App.onNavigate. Again, this is to allow managing the state of the UI in the top component. After passing onNavigate() down to the <EmployeeList /> React component, the following handlers are coded up to handle clicking on some buttons:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=handle-nav]

Each of these functions intercepts the default event and stops it from bubbling up. Then it invokes the onNavigate() function with the proper hypermedia link.

Now you can conditionally display the controls based on which links appear in the hypermedia links in EmployeeList.render:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=employee-list-render]

As in the previous section, it still transforms this.props.employees into an array of <Element /> components. Then it builds up an array of navLinks as an array of HTML buttons.

Because React is based on XML, you cannot put < inside the <button> element. You must instead use the encoded version.

Then you can see {navLinks} inserted towards the bottom of the returned HTML.

Deleting Existing Records

Deleting entries is much easier. All you need to do is get its HAL-based record and apply DELETE to its self link:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=employee]

This updated version of the Employee component shows an extra entry (a delete button) at the end of the row. It is registered to invoke this.handleDelete when clicked. The handleDelete() function can then invoke the callback passed down while supplying the contextually important this.props.employee record.

This again shows that it is easiest to manage state in the top component, in one place. This might not always be the case. However, oftentimes, managing state in one place makes it easier to keep things straight and simpler. By invoking the callback with component-specific details (this.props.onDelete(this.props.employee)), it is very easy to orchestrate behavior between components.

By tracing the onDelete() function back to the top at App.onDelete, you can see how it operates:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=delete]

The behavior to apply after deleting a record with a page-based UI is a bit tricky. In this case, it reloads the whole data from the server, applying the same page size. Then it shows the first page.

If you are deleting the last record on the last page, it will jump to the first page.

Adjusting the Page Size

One way to see how hypermedia really shines is to update the page size. Spring Data REST fluidly updates the navigational links based on the page size.

There is an HTML element at the top of ElementList.render: <input ref="pageSize" defaultValue={this.props.pageSize} onInput={this.handleInput}/>.

  • ref="pageSize" makes it easy to grab that element with this.refs.pageSize.

  • defaultValue initializes it with the state’s pageSize.

  • onInput registers a handler, as shown below:

    Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=handle-page-size-updates]

It stops the event from bubbling up. Then it uses the ref attribute of the <input> to find the DOM node and extract its value, all through React’s findDOMNode() helper function. It tests whether the input is really a number by checking if it is a string of digits. If so, it invokes the callback, sending the new page size to the App React component. If not, the character just entered is stripped off the input.

What does App do when it gets a updatePageSize()? Check it out:

Unresolved directive in hypermedia/README.adoc - include::src/main/js/app.js[tag=update-page-size]

Because a new page size value causes changes to all the navigation links, it is best to refetch the data and start from the beginning.

Putting It All Together

With all these nice additions, you now have a really vamped up UI, as the following image shows:

hypermedia 1

You can see the page size setting at the top, the delete buttons on each row, and the navigational buttons at the bottom. The navigational buttons illustrate a powerful feature of hypermedia controls.

In the following image, you can see the CreateDialog with the metadata plugged into the HTML input placeholders:

hypermedia 2

This really shows the power of using hypermedia coupled with domain-driven metadata (JSON Schema). The web page does not have to know which field is which. Instead, the user can see it and know how to use it. If you added another field to the Employee domain object, this pop-up would automatically display it.

Review

In this section:

  • You turned on Spring Data REST’s paging feature.

  • You threw out hardcoded URI paths and started using the root URI combined with relationship names or “rels”.

  • You updated the UI to dynamically use page-based hypermedia controls.

  • You added the ability to create & delete employees and update the UI as needed.

  • You made it possible to change the page size and have the UI flexibly respond.

Issues?

You made the webpage dynamic. But open another browser tab and point it at the same app. Changes in one tab do not update anything in the other.

We address that issue in the next section.

Unresolved directive in <stdin> - include::conditional/README.adoc[leveloffset=+1] Unresolved directive in <stdin> - include::events/README.adoc[leveloffset=+1] Unresolved directive in <stdin> - include::security/README.adoc[leveloffset=+1]

Want to write a new guide or contribute to an existing one? Check out our contribution guidelines.

All guides are released with an ASLv2 license for the code, and an Attribution, NoDerivatives creative commons license for the writing.