Why Everything Should Be RESTful

In my new position, I was recently tasked with rewriting an aging utility web application. The requirements were simple, but initially daunting: It needed to be written in JSP.

For the uninitiated, JSP is short for Java Server Page. Just like the name indicates, it’s Java. Specifically, it’s Java on an Apache Tomcat web server. JSP content is usually a combination of Java functions and HTML markup. At runtime, the JSP’s functions populate and manipulate the document that gets displayed on the client’s browser. It’s a similar paradigm in many ways to how PHP can be used to display dynamic content on the web.

The problem is, no one actually wants to mix their HTML markup into their back-end programming anymore. It’s an old-fashioned paradigm that results in messy spaghetti code that is difficult to maintain and often results in *.jsp files containing bits of HTML, JavaScript, CSS, and Java (or PHP, or whatever else you’re programming in), all interspersed with one another.

Fortunately, there is a style of architecture for the web that solves this problem: REST. It stands for REpresentational State Transfer. The idea is to provide an application programming interface (API) for clients to retrieve and manipulate data that isn’t constrained by the way that data is stored on the server. Conveniently, it also allows developers to decouple the view from the logic of retrieving and manipulating it.

Instead of digging through the previous project’s archaic structure and trying to upgrade it, I decided to take the comparatively easy route of rewriting the entire thing. It really was simpler; I used Java to construct a good RESTful API, which works entirely independently of whatever client attempts to use it, and this allowed me to write the front-end cleanly and separately. No mixing of multiple languages together.

The benefits of separating these concerns are many:

  • Let’s say somewhere down the road, our client decides to switch from Java to PHP (or Golang, or Node, or anything else). In that eventuality, the front-end will remain identical, and only the API will need to be ported over.
  • Or conversely, what if they decide they want a different interface? Great, the API will stay the same, we’ll just rework the front-end.
  • A mobile interface is now easy to implement. The API is completely agnostic about what the client happens to be running on. As long as it authenticates properly, the API will serve up data to whatever asks for it.
  • If/when bugs are discovered, it will be immediately apparent which part of the program they’re occurring in, and it will be easy to fix them.
  • New features will be easy to add. If the data they rely on is derived from the existing dataset already being provided by the API, there won’t even need to be any additional work on the API.

In the end, I have to admit, I’m a bit of a lazy dog. Good developers always are, and I want to be good at what I do. Rather than go the extra mile, learn the intricacies of an old legacy system, and spend months trying to upgrade it, I said, “Why not just make something quick and easy?” And in doing so, I made something far superior and very maintainable, easing the burden on our client, my coworkers, and (most importantly) me in the process.

That is ultimately why everything should be RESTful. Anything else is just too much work.