Enterprise Integration Zone is brought to you in partnership with:

Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others. Matt is a DZone MVB and is not an employee of DZone and has posted 144 posts at DZone. You can read more from them at their website. View Full User Profile

RESTful Web Applications with Subbu Allamaraju

11.03.2008
| 9847 views |
  • submit to reddit
Subbu works at Yahoo! developing standards, patterns and practices for HTTP web languages. In the past, he was a web service and Java developer. He was also a standards contributor at BEA and an author of books on Java EE. His current passion is HTTP and REST. Subbu confesses that he's not a web developer, has no interest in the internals of programming models used for web frameworks and he's only interested in the visible aspects of the architecture.

"The Web is Mostly Restful"

Being RESTful in an abstract sense means:

  • Resources are named by URIs
  • Resources have representations (Atom, HTML, JSON, XML)
  • Resources contain contextual links to allow navigation of state
  • There's a Uniform Interface

In the web today, some resources and URIs are personalized, but most are not. Some depend on sessions, but most do not. The consequence of a personalized UI with a non-unique URI is you cannot rely on browser caching.

The web is full of different representations (HTML, XML, JS, PDF, CSS, Flash). The problem with HTML is you can't tell links that you want a particular representation based of a link. The links are hard-coded to be a particular content-type. However, some media types on responses are ignored. This is often a problem with browsers and whether the user has plugins installed.

The Uniform Interface for the web is HTML and primarily links and forms (GET and POST). There's still some misconceptions (e.g. POST is secure). However, it's not about security, it's about idempotency and safety. You need to make sure you only use POST when you're changing data. POSTs are not repeatable. GET URIs are not always refreshable, which is quite unfortunate. Users shouldn't have to fight the back button.

Caching is a fundamental aspect of the web. Even in a personalized site, most of the content can be cached. The web is read-only for the most part. However, many enterprise web applications don't take advantage of caching. This is fine when there's not that many users, but it's bad when you want to scale to thousands of users. There's several frameworks that use cache-busting and prefer backend caching over HTTP caching. These frameworks are not using the web like they should.

Backend caching (e.g. Memcached) uses a non-uniform interface and you need to explicitly program to it. Frontend/HTTP caching has a uniform interface that's pluggable. Backend caching is generally more expensive to develop and deploy. There are cases where data should be cached on the backend, but you shouldn't focus all on backend caching w/o doing some frontend caching.

With Ajax, you get more opportunities to be RESTful. XMLHttpRequest is another HTTP client that can be programmed to. It has full support for the uniform interface, which allows content negotiation, optimistic concurrency and caching. Cross-domain hacks can be done with <script> and <iframe> to tunnel requests over GET. The W3C has been working for the last two years on how to do cross-domain Ajax w/o using hacks. The problem with current cross-domain implementations is they often use GET for everything, which isn't very RESTful. Subbu recommends using a proxy on the same domain if you do need to talk to other domains. This will allow your Ajax code to remain RESTful.

Web Frameworks
Web development is hard because of all the moving pieces that exist. Because of this, many web frameworks have been created to solve the various problems. In 1997, there were servlets. They provided basic plumbing and closely reflected HTTP/1.1. Servlets provided a poor programming model, but it allowed a lot of frameworks to be built on top of it. We don't use servlets to write applications, only to write application frameworks. The second era came about in 2001 when Action-oriented frameworks became popular. In 2004, JSF and friends came to play. JSF is a component-based framework with known limitations (complex, slow, uses POST for almost everything, Ajax is difficult). These limitations have resulted in a number of third-party patches being developed to solve these issues.

JSF was designed to use the request to create a component tree that maintains state. Unfortunately, the state is not something the developer has control over. It's not the state of the application, it's the state of the components. The client's knowledge of the state is mentioned with a cookie and the server keeps the state in the session. The problem with JSF is you don't have a choice of state in your application - you can't write stateless applications like you can with servlets.

JSF uses overloaded URIs for its resources. When you have one URI with multiple representations, there's no way to tell how a representation was chosen. JSF's compromise is to allow client-side state saving. However, they do this by putting hidden field in the form and requiring POST for navigation.

JSF vs. REST
Basically, these two are at opposite extremes. JSF is focused heavily on a UI component model. The people that developed it misinterpreted how the web works and made some fundamental questionable choices. You can patch it, but you can not fix it.

Web 2.0 Frameworks
GWT is a cross-compilation based framework. You write Java to generate JavaScript (b/c everyone hates writing JavaScript). It mashes client and server code into a single source. These layers communicate using GWT-RPC. Typical RPC concerns do not apply since code generation handles coupling and the client is downloaded from the same application. GWT-PRC does POSTs to the server and uses HTTP like a transport layer. To be fair, GWT does allow you to use a RequestBuilder to use the web like it should be used. This class allows more control over HTTP requests, it supports GET and POST and it allows so-called RESTful layers (GWT-REST and GET-Restlet). GWT is focused heavily on ease-of-use, which is good. It's modeled after RPC and breaks the uniform interface and focuses on backend caching. Unlike JSF, GWT is fixable, but the community tends to use RPC instead of RequestBuilder.

SOFEA has a central promise of SOA. Business logic is a reusable service that changes less often. The presentation application calls those services and changes more often. The nice thing about this type of architecture is it allows a separation of concerns and loose coupling. However, it doesn't embrace REST like it should. Appcelerator is an implementation of SOFEA that has a Ruby on Rails-like usability. However, it uses a SOAP/HTTP style with messaging and POSTs to a single URI. Appcelerator is interesting, but it introduces a different style of coupling. It breaks URI opacity and client deals with POX instead of links.

Conclusion
Don't fight the architecture of the web. Innovate and enhance instead of breaking. If nothing else, break judiciously. As developers, we should demand more from our frameworks and make sure they use the web and HTTP like it should be used.

From Raible Designs

Published at DZone with permission of Matt Raible, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ivan Lazarte replied on Mon, 2008/11/03 - 3:42pm

I love writing Javascript :(

(Provided my JS ide uses JsLint) 

Mike Funk replied on Tue, 2008/11/04 - 7:13am

Okay, Matt, so what's the answer? Is there a client/server technology stack that allows for true restful web development?

Fab Mars replied on Tue, 2008/11/04 - 9:33am

[quote]Basically, these two are at opposite extremes. JSF is focused heavily on a UI component model. The people that developed it misinterpreted how the web works and made some fundamental questionable choices. You can patch it, but you can not fix it.[/quote]

Here we go again. This relentless cabal against JSF gets really annoying and misplaced, not to say unfair.

 

 "JSF is a component-based framework with known limitations (complex, slow, uses POST for almost everything, Ajax is difficult). These limitations have resulted in a number of third-party patches being developed to solve these issues.": I completely disagree here...unless the author is speaking about JSF 1.0. There have been lots of improvements, the response time remains above many other frameworks, GET is perfectly possible with little code, and Ajax is hard with every framework. The word "patches" is purposedly misused here, and the word "being" tends to highlight the fact all is WIP, whereas there are working libraries for a long time already. What if I wrote "Hibernate is an ORM framework with known limitations (no end-to-end validation, no EJB3 compliance). These limitations have resulted in a number of  patches (Hibernate Validator, Hibernate Entity Manager) being developed to solve these issues." This just sounds bogus.

 

  "The people that developed it misinterpreted how the web works": That sounds so abstract and anyway expresses one's opinion of how the web works. Funny. However there are galore people here with real-working JSF applications running in the real world that can contradict it.

 

 "You can patch it, but you can not fix it.": Again the negative phrase "patch" here. Besides, this is a copy-paste from another very questionable article. JSF, like every other framework had limitations in its first versions. All frameworks evolve as their creators work to solve the limitations. If we had to wait for every framework to solve every given problem potentially encountered at development time, we could wait forever. Who can say EJB2 or Hibernate2 were flawless? Come on. I can think about specific issues in some widely used frameworks that are considered as "features" by their developers. At least the JSF workgroup is listeninig to users. Accordingly, JSF is bound do evolve.

 

And lastly I don't understand how someone can just write a "JSF vs REST" title. Oh actually I understand when I read "Web 2.0 frameworks" in the next paragraph. Well, it's absurd; it's pure theory.  JSF is a framework, ReST is a concept. Even REST implementations cannot be compared to what JSF does because there are different purposes at stake here! Why not write instead "SAP vs SOA", or "Red cars vs. LPG cars" ? JSF and ReST can be used together to solve a part of some busineess requirments encountered in nowadays projects. That's how you can buy red cars working with LPG now :)

  I don't mean at being harsh here, but I had to react. This place shouldn't let publish such biased content.

James Clinton replied on Thu, 2008/11/06 - 5:34pm

OK article, but had to dis-agree on comments regarding JSF.

 JSF may not be perfect but it does a good job when used with the right supporting framework (Spring or Seam).  Also adding AJAX is JSF is very simple thanks to ajax4jsf which is now part of seam.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.