Lesson Tuesday

In the previous lessons we added a ton of new, complex features to our application back end. Our Post objects now contain IDs, date stamps, and booleans indicating whether they're completed. Our Post class can also record and return all Posts, clear all Posts, and locate a specific Post based on its unique ID. Very nice work implementing all this functionality; that's no small feat!

But so far, we haven’t spent much time building out the frontend - we’ve been focusing on getting our backend methods setup and tests passing. If you recall, we stopped working on our frontend at this point:

my-epicodus-blog/src/main/java/App.java
public class App {
   public static void main(String[] args) { //type “psvm + tab” to autocreate this!
       staticFileLocation("/public");

       get("/", (req, res) -> {
           Map<String, Object> model = new HashMap<>();
           ArrayList<Post> posts = Post.getAll();
           model.put("posts", posts);
           return new ModelAndView(model, "index.hbs");
       }, new HandlebarsTemplateEngine());

       //route that makes new post
       post("/posts/new", (request, response) -> { //URL to make new post on POST route
           Map<String, Object> model = new HashMap<>();

           String content = request.queryParams("content");
           Post newPost = new Post(content);
           model.put("post", newPost);
           return new ModelAndView(model, "success.hbs");
       }, new HandlebarsTemplateEngine());
   }
}

Not quite tumbleweeds, but we’re not really doing much with the awesome backend functionality we just wrote either. In this lesson we’ll build out our frontend.

But before we do that, It’s time to learn something awesome and important you’ll see reflected in many a job posting and that will stay with us for the rest of our time here at Epicodus. And that thing is called, aptly maybe, REST.

What is REST?

REST, which stands for Representational State Transfer, is a set of standards for creating efficient, reusable routes and pages. These conventions are used across many languages and frameworks, and they make it easy for other developers to quickly understand and navigate an application.

Essentially, this means that the state of the application should be clearly represented as information is transferred from page to page. You’ll frequently hear the term REST when discussing APIs, as those are often created with these standards in mind. And as we will be working with a great many of RESTful APIs, not to mention creating our own in week 4 of this course, we'll explore these very standards in-depth.

The state in representational state transfer is actually a reference to the statelessness of the HTTP protocol, which is what the world wide web is based upon, specifically. What on earth do we mean? Is this a zen thing?

Statelessness is the “state” of each request or response sent to or from a server being a complete package.

When we send a request to the server, it receives that request, and has all the information it needs to execute an action based on that request. No additional information is needed, and nothing tracks the state while it is unfolding.

From Wikipedia: “In computing, a stateless protocol is a communications protocol that treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of requests and responses. A stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests.”

Imagine a tennis player playing a ball to another player: Once the ball is fired off, it can be received and an action happens as a return immediately. The transaction is immediately complete.

An example of a stateful protocol: Our tennis player goes to buy a new racket, and is issued a receipt. The server retains a copy of the receipt. The tennis racket can be returned within 30 days, after which the return will be declined. The server (store) retains information about the racket’s return state, which changes over time.

REST is Representational, meaning, the URL indicates the state transfer that is about to unfold - a request for information changes to a response with said information, back to the client.

REST standards allow us to quickly:

a.) interpret what our user is trying to do with our app b.) choose the data we need to make available to them and c.) use the appropriate view layer (template) to display that data correctly.

RESTful Routing

The general convention for RESTful routing in an application with one primary type of object to list, create, and display details for looks like this:

general-RESTful-routing-guide

  • Here, the red text represents the name of the object the application is managing. For instance, Post, CD, or JobOpening.
  • The green text represents names that don't have to follow the pattern depicted above, but it's generally considered good practice to. As you can see, these are names for things like template files, and keys for values we place into model.
  • The blue text represents variable names and form name attributes that may be called whatever you'd like.
  • The purple text represents methods you should define in the class you're working with.
  • The orange text may change, depending on the datatype of the information you're providing to your object's constructor.

Applying RESTful Routing to our Blog

Now that our applications have become complex enough to include many interconnected pages, we'll begin using the RESTful pattern to create our routes. Additionally, following the RESTful route conventions will be required throughout the remainder of the course.

Below is the RESTful routing template we reviewed above, filled in with details specific to our Blog:

Etc.

Now, this may seem like a lot to take in. That's normal. After all, there's a lot of code in that diagram! However, believe us when we say this will actually make routing easier. Not only does utilizing RESTful route patterns follow the best, most professional practices, but it also offers us a template we can use for any application.

Instead of contriving your own routes, you can simply utilize the standard RESTful routes and insert your own information! Refer back to either of these diagrams as much as you need to while developing future Spark applications with RESTful routes.

Blog User Interface

Let’s build out our app to use RESTful routes. Before we begin coding, let's discuss each functionality our application will demonstrate, and what its user interface will look like. The bullet points below correlate with the Spark routes we'll create:

  • Homepage. We previously listed all Posts on the homepage. Now that our application is more complex, let's reorganize it into multiple pages. Each page will be dedicated to a specific function. For our homepage, we'll just include a basic welcome message and some links.

  • New Post Form. We need an area where we can fill out and submit our form to create a new Post. We already have a form, but we'll move it to its own dedicated page.

  • List of All Posts. We know we'll need a page that lists all posts. After all, that's the purpose of a Blog!

  • Detail View. We discussed this briefly in the previous lesson. Now that each Post contains multiple details, such as its time of creation, instead of listing all details for every Post in the page described above, we'll implement a detail view. A user should be able to click on a specific Post in the list to see a page displaying all of its details.

Move on to the next lesson to get a start on coding out the “rest” of our functionality. </dadjoke>