Saturday, December 22, 2012

Plain-vanilla Java Servlets and Pretty URLs

I'm writing this because I was recently asked about the growing complexity of Java-based web MVC frameworks. It made me think about the kinds of web applications a Java developer can build with just the plain-vanilla Java Servlets.

As I was pondering on the thought, I could not help ask myself about the following:

  • What happens to pretty URLs?
  • How can we add page templates like those provided by SiteMesh and Apache Tiles?

Pretty URLs and Mapping Conventions

It's common nowadays to consider question mark (?) and ampersand (&) characters in the URL as being ugly. But are they really that bad? Do they really affect SEO in a negative way? The truth is... it is just a myth. Why would Google (and other search engines) put so much weight on the URL? Fact is... Google will (and should) do a good job by looking into the contents the URL is pointing to. It should not just be looking at the URL. If it did put so much weight on URLs, then we'll all be filled with spammed links by those who just want to be on top of SERPs.

If so, how do we now map URLs to Java servlets? Below show the typical URL mapping.

MethodURLAction
GET/magazinesindex (default)
GET/magazines/{id}show
GET/magazines/{id}/editeditRender HTML form for editing magazine with given {id}
PUT/magazines/{id}updateUpdates magazine with given {id}. Redirect to GET /magazines.
GET/magazines/newnewRender HTML form for new magazine.
POST/magazinessaveSave magazine ad and generate new unique ID. Redirect to GET /magazines.
DELETE/magazines/{id}deleteRemove magazine with given {id}

Given the above URL mappings, it's impossible to implement using a web.xml. So, are we really forced to use the above conventions? Are we really forced to use a single servlet, mapped to /app/*, and have it apply a regular expression to determine which controller should handle the incoming request?

IMO, we should not be forced to do so. Assuming you'd allow URLs that contain question marks (?) and ampersands (&), we can have the following mappings.

MethodURLAction
GET/magazinesindex (default)
GET/magazines?id={id}show
GET/magazines?id={id}&editeditRender HTML form for editing magazine with given {id}
PUT/magazines?id={id}updateUpdates magazine with given {id}. Redirect to GET /magazines.
GET/magazines?newnewRender HTML form for new magazine.
POST/magazinessaveSave magazine and generate new unique ID. Redirect to GET /magazines.
DELETE/magazines?id={id}deleteRemove magazine with given {id}

The above mappings are definitely possible to implement in a web.xml. It just needs a servlet mapped to /magazines/*. It will also need a filter to support the translation of PUT and DELETE methods (as most browsers only support GET and POST). As for nested resources/namespaces, a similar approach applies. It will need another servlet mapped to /magazines/ads/*.

MethodURLAction
GET/magazines/ads?m_id={magazine_id}index (default)List ads under the magazine with the given {magazine_id}.
GET/magazines/ads?m_id={magazine_id}&id={id}showShow magazine ad with given {id}.
GET/magazines/ads?m_id={magazine_id}&id={id}&editeditRender HTML form for editing magazine ad with given {id}
PUT/magazines/ads?m_id={magazine_id}&id={id}updateUpdates magazine ad with given {id}. Redirect to GET /magazines/ads.
GET/magazines/ads?m_id={magazine_id}&newnewRender HTML form for new magazine ad.
POST/magazines/ads?m_id={magazine_id}saveSave magazine ad and generate new unique ID. Redirect to GET /magazines/ads?m_id={magazine_id}.
DELETE/magazines/ads?m_id={magazine_id}&id={id}deleteRemove magazine ad with given {id}

To extend the conventions further, each servlet acting as controller (in MVC) should forward to a view (typically implemented as a JSP). These JSPs can be located under /WEB-INF/views/magazines and /WEB-INF/views/magazines/ads to match their servlet URL mappings.

Templating Frameworks

I find it more and more common to use SiteMesh or Tiles in developing Java-based web applications. In fact, it would be uncommon to see a Java web application that does not use SiteMesh or Tiles.

After doing some research, I found a lesser known feature of Java Server Pages (JSPs) 2.0: <include-prelude> and <include-coda>. These allow developers to have templates included in the beginning and end of all JSPs that matched the URL.

An example configuration in web.xml looks like this:

  <jsp-config>
    <jsp-property-group>
      <url-pattern>*.jsp</url-pattern>
      <include-prelude>/WEB-INF/includes/prelude.jspf</include-prelude>
      <include-coda>/WEB-INF/includes/coda.jspf</include-coda>
    </jsp-property-group>
  </jsp-config>
The *.jspf is just a common filename extension for JSP fragments.

If the page layout is simple enough to allow a header and footer implemented as a prelude and coda, then using this JSP 2.0 feature should do the trick.

Conclusion

So, is it really that bad? What do you think?

IMO, it's not that bad. There's definitely more to building web apps using just plain Java Servlets and JSPs. But these alone are quite powerful. And the MVC frameworks enhance it further.

That's all for now. Happy holidays!

2019 September Update

If you'd like to know more, checkout how a Java Servlet works. It even contains a cool trivia about the people who created the Java Servlet 1.0 specification! Happy reading!

1 comment:

  1. Thanks, this is generally helpful.
    Still, I followed step-by-step your method in this Core Java online course
    learn Java online

    ReplyDelete