There is no exact definition of the REST protocol. It stands for Representational state transfer, which probably does not mean a thing to someone who has never heard of it. When we program the REST API, we use the HTTP(S) protocol. We send simple requests to the server, and we get simple answers that we program. This way, the client of the web server is also a program (by the way, the browser is also a program) that consumes the response from the server. The format of the response, therefore, is not HTML formatted using CSS and enriched by client-side functionalities by JavaScript, but rather some data descriptive format such as JSON. REST does not set restrictions on the actual format, but these days, JSON is the most widely used.

The wiki page that describes REST is available at https://en.wikipedia.org/wiki/Representational_state_transfer. REST interfaces are usually made simple. The HTTP requests almost always use the GET method. It also makes the testing of REST services simple since nothing is easier than issuing a GET request from a browser. POST requests are only used when the service performs some transaction or change on the server, and that way, the request is sending data to the server rather than getting some data.

In our application, we will use the GET method to query a list of products and get information about a product, and we will only use POST to order products. The application that serves these requests will run in a servlet container. You have learnt how to create a naked servlet without the use of a framework. In this chapter, we will use the Spring framework, which offloads many of the tasks from the developer. There are many program constructs in servlet programming that are just the same most of the time. They are called boilerplate code. The Spring framework utilizes the Model View Controller design pattern to develop web applications; thus, we will look at it in brief, before discussing Spring in general.