An Introduction to RESTful Web Services in Java

by Jul 14, 2015

An Introduction to RESTful Web Services in Java

This video introduces you to the tools for writing RESTful web services in Java. It was originally part of a larger unpublished video tutorial on creating JAXRS applications using Java.


Hi and welcome to Creating RESTful APIs for your mobile apps using Java. This course will introduce you to creating RESTful APIs using Java. We are going to cover not only the code you’ll use, but also the tools used to create a professional Java application. There’s no time like the present, so let’s get started.

In this video we will introduce web services. These are services computers use to communicate information between computers. Then we will talk about RESTful web services. These are services created using the RESTful architectural style. We will also take a look at the advantages of RESTful APIs over other API types. Finally we’ll take a look at the basic layers to a RESTful application.

Web services

The whole point of creating an RESTful API is to get two computers to talk to each other.

We might need to notify another computer of an event, make a request to buy airline tickets, or maybe we’re just trying to share some deep insight using 140 characters or less. No matter what we’re trying to do, we need to move information from one computer to another.

We can move this information by directly connecting the computers, but that breaks down as soon as you try to connect more than a few computers. You need to network the computers in some fashion. To make sure the largest number of computers can talk to each other, you want to use a network that you can guarantee most computers can use. That network of course is the internet.

Applications communicate with each other using web services over HTTP. HTTP is a protocol that stands for hypertext transfer protocol. You don’t need to remember that, you just need to know that HTTP describes the rules for how information is transferred from one computer to another over the web.

A web service is a standard way for web based applications to pass messages over the internet. A web service usually performs a single action on behalf of the machine making the request. The machine making the request is called the client, and the machine hosting the web service is called the server.

The web service code is executed on the server. There is no user interface for these services, only information is communicated in the messages. Client web applications can build on these web services to provide a user interface, and solve a larger problem.

A web service allows single actions like “get me the list of Green Lantern comics from 1980 to 1981”. Getting the list of Green Lantern comic books would be a simple request. Once the server has fulfilled your request, your conversation is over.

A larger workflow, like purchasing an airline ticket, would require a longer conversation. Usually these longer conversations can be broken down into simpler web services. So purchasing a airline ticket, might be broken down into smaller steps like validate credit card, charge credit card, and reserve plane ticket.


REST is an architectural style that stands for Representational State Transfer. The term REST and the ideas behind it were first coined in 2000 in the doctoral dissertation by Roy Felding. Systems that follow Dr. Felding’s principles described in his dissertation are called RESTful. So what are those principles?

The main architectural principle of RESTful systems is everything is defined by the data. In REST the data is called a resource. Every resource has a unique addressable location. This is represented by a web address. Just like getting a web page in your browser, getting a RESTful resource is simple as “give me the resource at this url”. In this example, we are defining Green Lantern comics as our resource. We can ask for a single issue by adding an id to the endpoint, in this case 148. This means the data for the Green Lantern comic number 148 is located at this endpoint.

REST is HTTP. The REST commands are the same well defined HTTP commands. GET returns a state representation of the resource requested. POST creates a resource. PUT updates a resource at a identified resource. DELETE, well that’s obvious. It deletes the resource.

The resources are returned in the form the client requests. This just means you can ask for a resource in the format you want, and if the REST API supports it, you will get the resource in that format. If you ask for the resource as XML and the API can represent your the resource as XML, the API will return your resource as XML. This is called content negotiation, and we’ll cover it in depth soon.

REST is stateless. You ask for a resource, and you get the resource in the state it exists at the time your request it. After that, the conversation with the server is over. This is something to keep in mind if your application needs to insure it’s working with the same resource that exists on the server.

The last principle is a mouthful. Hypermedia is used as the engine of application state. Basically this means the resource that is returned to you, also includes what interactions with the server you can have next. If you ask for a page in a book, you should also include links to the next page and the previous page. A user should be able to make requests to a single API resource, and be able to programmatically navigate your entire API.

Advantages of REST

REST has several unique advantages over other web service technologies.

It’s very simple. Since it’s based on HTTP, it’s very familiar. Most programming languages already know how to make HTTP calls.

Every resource in your system is represented by a URI, and users already know how to use your system. There are a limited number of verbs. GET, POST, PUT and DELETE convey the intention of the service. This makes the REST calls self descriptive.

REST is very lightweight compared to other solutions like SOAP or RMI. REST calls can easily be made from AJAX on a web site, or from a mobile application. Mobile devices have limited capabilities, so a lightweight solution can’t be over stated.

As you will see in this course, REST APIs can be implemented and deployed very quickly. The code is very simple, which makes it easy maintain. Development can be scaled too, since each resource endpoint can usually stand on it’s own.

Since REST applications are really just web applications, all the benefits from web applications apply. You can cache the results from GET requests. You can place your REST server behind a load balancer for easy scaling. You can even test your calls from a browser.

Layers of REST

There are several layers which comprise a REST application. These are the client layer, the presentation layer, the domain layer, the data layer, and the data store where your resources are persisted.

The client layer contains the applications which access your REST API. This would be your mobile application, or your web pages. Since almost any language can make REST calls, the tools you use at this layer can differ from project to project, or even within the project.

The presentation layer is the layer made from your REST endpoints. These are the classes that responds to the client requests. We will use something called the Java API for Restful Services for this layer.

The domain layer is the layer that knows how to build the resources for the presentation layer. This layer has your domain or business objects that represent your resources. The rules specific to your business live here. This is custom code you write inside of enterprise Java beans.

The data layer holds the classes that represent your data. The data objects are not necessarily the same as your resource objects. The domain objects usually are built from multiple data objects. We will use the Java Persistence API for this layer.

The data store is where the data ultimately lives. This could be a relational database such as MySQL or Oracle, flat files, or what ever method you use to store your data.


So now you know RESTful applications are web service applications which map to HTTP. Any application which adheres to the principles outlined by Roy Felding are considered RESTful.

You’ve seen that RESTful applications have numerous benefits over other technologies including simplicity, familiarity, size, maintainability, and scalability.

We’ve also covered the basics of the different layers we are using to architect our RESTful application.

In the next video we are going to cover the tools used in each layer.

Tools Used

  • Java
  • NetBeans

Media Credits

All media created and owned by DJ Spiess unless listed below.

  • No infringement intended

Get the code

The source code for “An Introduction to RESTful Web Services in Java” can be found on Github. If you have Git installed on your system, you can clone the repository by issuing the following command:

 git clone 

Go to the Support > Getting the Code page for more help.

If you find any errors in the code, feel free to let me know or issue a pull request in Git.

Don’t miss another video!

New videos come out every week. Make sure you subscribe!



DJ Spiess

DJ Spiess

Your personal instructor

My name is DJ Spiess and I’m a developer with a Masters degree in Computer Science working in Colorado, USA. I primarily work with Java server applications. I started programming as a kid in the 1980s, and I’ve programmed professionally since 1996. My main focus are REST APIs, large-scale data, and mobile development. The last six years I’ve worked on large National Science Foundation projects. You can read more about my development experience on my LinkedIn account.

Pin It on Pinterest

Share This