Introduction
This article proposes a UI perspective on REST. Part 2 of this article (to be updated soon) presents C# and Java examples about what Standalone AJAX is: an UI perspective on REST.
Background
Some time ago, I was reading an article about possible technology trends like having AJAX standalone - not needing any more ASP or JSP or PHP, etc. I didn't know about REST at that time and how REST can clean all the heavy server technologies.
Doing AJAX enabled "server pages" within my projects was not a convenient task sometimes. Why bother with e.g., viewstate, how about not needing it at all? All you need is HTML, CSS, and
JavaScript as a client side able to consume services.
I think MVC in the way we know it is more or less dead. Replacing "only" the thin view to suit different devices is a joke that only sounded good in theory. "Building web applications" now means more and more "integrating client applications to consume services". We heard about SOA in the past, but we needed the explosion of the devices market to really turn the industry towards really robust standards instead of just selling technology - essentially only "newer versions of the same thing" with expensive tools to handle the complexity for you. You try to do SOA, then some MVC sharing the model with the SOA part, and you end up with a tightly coupled design pattern-ized structure (complexity with different names), or if you dare to decouple things it may become even more complex.
Standalone AJAX - An UI perspective on REST
Let's say we need to build a Web application based on some initial discussions that end up by not giving a clear overview of the functionality (as usual), so you can
first build an incomplete skeleton.
We are in the first sprint... some Agile teams may struggle already to deliver "usable software"... well, bits of it... then change it later with great agility and... under the pressure of changing requirements - most of the time the client needs to achieve a better structure for
their own processes before it would make sense to have custom software... The sooner you get better requirements, the lower the costs will be. Most clients want to see something before getting really involved. It would be great to provide ASAP a live Web site and let the client play around and get the feeling, understand the gaps... and it would be the static HTML itself that you will use further to finish the development.
- On the client... now having most of the functionality clarified by the already "moving" static HTML prototype, it is time for
a few more sprints. It is time to go further with the Web design on the live HTML - you don't have to bother the Web designers anymore with some ASP or JSP or PHP since they usually "like" HTML, CSS and PhotoShop, and also you don't have to drive the developers crazy to reproduce some web designer "crazy ideas"... nice on HTML but scary from within the "X" Server Pages script. Just refine the web design and, when "some server side" is available, add the AJAX call layer, the guys doing those don't even need to be in the same room... not that good communication is bad, I only want to point how decoupled things could be.
- The server side... as soon as you understand how the database can be and what business logic you may need (even in the first sprint in parallel with the rapidly growing static HTML presentation), start to build a server side call skeleton with methods returning even test hard-coded data, with unit tests if you do TDD. The goal is to supply ASAP the server side to support the first AJAX calls... from the already good looking web site... and go to the client again... he will be thrilled about how fast his software grows tailored to his needs... and will pay attention to clarify all that you need.
- Now it is mostly clear what to do, so just test and refine the application, e.g., exchange the shortest JSON messages possible.
- And if the client suddenly discovers that they will have 1000 times more hits than expected... just deploy the server side on some bigger machines, app server, or better OS.
Points of Interest
- Avoid requirement document overheads, allow the functionality to be clarified on live components: what you see is what you get, also a good approach to "get" the client.
- Fancy web design is no longer a problem for learning developers.
- Be focused on writing loosely coupled data services in a RESTfull manner. Why waste server resources to render "dynamically static HTML" when you mostly can avoid it? If you really want, your representations could be HTML but the most important on the ROA server side is an elegant API ready to be consumed by any client, not only your "website".
- Keep the AJAX and JavaScript layer simple. Also be aware to not bloat the app. server with AJAX calls...
- Try to involve TDD on the server side that is an API - the client will discover new "desires" right before the deadline... and how else can you rely better on your code?
- XML is great if you can reduce the database complexity or even if you may need to apply some XSL, but don't overuse XML, JSON could be better.
Standards are good but you may not need SOAP, a simple HTTP servlet is already a service. Not drowning in technology... that can greatly reduce costs.
Hope this helps.
History
- 8th July, 2008: Initial post.
- 20th September, 2009: Article updated.
