Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
SYS-CON.TV
Today's Top SOA Links


Toss Your Cookies: Maintaining State on the Client with REST
Feel free to transfer application state to the client and rest assured you’re following REST.

REST quiz of the day: which is more important when following REST: updating the resource state or updating state on the client? Most developers are likely to say that REST focuses on updating resource state on the server. After all, POST, PUT, and DELETE all do so. GET is the only HTTP verb that fetches resource state without changing it.

If you've been reading ZapThink's discussion on REST, you probably realize that those developers are incorrect. Updating resource state is clearly an important part of REST, but updating state on the client is even more important. Why? Because client state is the foundation for distributed hypermedia applications. And after all, such applications are the point of REST.

In fact, the RESTful world distinguishes between resource state and application state, which is the state information the client maintains. And since hypermedia are the engine of application state, it makes sense that application state is more important to REST than resource state. After all, REST is representational state transfer. The representations are what the resources send to the clients, including application state information that belongs on the client.

HATEOAS and the Cloud
The topic of application state came up in an interesting discussion during our recent Cloud Computing for Architects course in San Diego. I was explaining how it's important to maintain a stateless application tier in the Cloud, because we want to put the components on that tier (Web servers, application servers, ESBs, etc.) onto virtual machine (VM) instances. In order to achieve the elasticity and resilience of the Cloud, then, we can't afford to maintain state information on such instances. We always have the option of persisting such state information, making it a part of the resource state, but relying too heavily on our resource state limits our scalability. The clear alternative is to transfer state information to the client, and let hypermedia be the engine of application state (otherwise known as the dreaded HATEOAS REST constraint).

One of the attendees in the class was confused by this discussion. He pointed out that if we use the client (say, a browser) to maintain state in a stateful application like an eCommerce shopping cart, then such state information must either go into hidden form fields or into the URL, so that the server can pass it along to the browser from one request to the next. But if the user is clicking a link rather than submitting a form, then they are executing a GET, and with a GET, the only place to put state information from the client to the server is in the URL. And we all know that URLs have a maximum length. What do we do, he asked, if we have too much state information for the URL? For example, we might have dozens of items in our cart. Was I suggesting passing the entire contents of each cart - product descriptions, prices, etc. - in the URL?

The answer, of course, is no. I say "of course" because such a question would be silly for anyone who truly understands REST. But I must admit, it took me a while to think through my response. The problem was that I have a background as a Web developer, and my student may have also built his share of Web sites back in the day as well. And back in the 1990s, before REST, in the early days of HTML and JavaScript, maintaining state in a browser was problematic. All we had were cookies and the aforementioned hidden form fields and URL query strings. And since people can turn their cookies off, we never wanted to rely on them. So yes, back in the day, if the user is clicking a link (i.e., performing a GET), the URL was all you had to work with.

With REST, however, we're working with an abstracted client. It need not be a browser, and in fact, it need not have a user interface at all. A RESTful client may serve as an intermediary, for example. Even when the client has a UI, it could be any type of application. For example, most mobile apps are written natively to the mobile environment (iPhone or Android, for the most part), and will continue to be at least until HTML5 is fully baked.

Even when the client is a browser, however, we have numerous ways of maintaining application state. Each approach, as you might expect, has its strengths and weaknesses:

  • Cookies - long a part of the HTTP protocol, cookies are universally supported and almost as universally reviled. We love them for enabling the "remember me" feature on Web sites with logins we visit frequently, and we hate them for enabling advertisers to track our browsing habits. Few app developers would rely on them for much else.
  • Hidden form fields - every Web developer's secret sauce. You can put whatever you want into such fields, and as long as the user submits the corresponding form, the contents of hidden fields go along for the ride. The problem is that hidden form fields only work with POST. In REST, POST is only for initializing a subsidiary resource, so if that's not what you're doing, then you don't want to POST. The other downside to hidden form fields is that application state information must always make a round trip to the server and back again, whether the server needs to do anything with it or not.
  • Frames - Frames made their debut in 1996 in Netscape Navigator 2.0, the same browser that introduced JavaScript to the world. Iframes came soon after. Both types of frames allowed new pages in the frame while maintaining state information in JavaScript variables in the enclosing page. In either case, however, updating the content of a frame doesn't change the URL in the browser's location field. As a result, reloading or following a bookmarked page takes you back to square one, deleting all state information.
  • JavaScript-only updates - More recent advances to the Document Object Model (DOM), in particular the innerHTML property, allow JavaScript to update any <div> element after the page is loaded. And since JavaScript can also perform all manner of RESTful calls, it's possible to make it appear that any or all of a page is changing, even though the page itself isn't actually reloading. As with frames, JavaScript variables can store state information, but also similar to frames, the URL the user sees doesn't change when your script interacts with the server.
  • Signed scripts - What about simply writing arbitrary content to the user's hard drive? Browser publishers have been monkeying with this capability since signed scripts debuted in the 1990s. The problem with giving the browser write privileges, of course, is security. One flaw and hackers can easily take over your computer. Needless to say, this capability never took off, although plugins like Adobe Flash can allow the ability to write to the users' hard drive.
  • DOM storage - Today we have DOM storage. Think cookies on steroids. Every modern browser can essentially store a JSON object that persists as the browser loads different pages. You have the option of maintaining such information for a browser session (you lose it when you quit the browser) or persisting it across browser sessions (where the browser writes the data to a file). This capability also enables developers to write browser apps that can function properly when the user is offline. The downside to DOM storage is that it only works in newer browsers - although Firefox, Internet Explorer, Chrome, and Safari all support it.
  • URL query string - finally, let's discuss storing state information in the URL. Yes, there's a character limit - the HTTP spec recommends sticking to 255 characters or less, although most browsers and Web servers support much longer URLs. So, how much can you cram into 255 characters? More than you might expect, if you use a tool like RISON for compacting JSON to squeeze more of it into each URL. Don't like RISON? There are alternatives available or you can create your own approach. Even with such techniques, however, there is still a size limit, and all such information must make the round trip to server and back.

The ZapThink Take
Based on the discussion above, you should have no more concerns about storing application state on the client. There are always tradeoffs, but one of the scenarios above should handle virtually every application state issue you're likely to come up with. Feel free to transfer application state to the client and rest assured you're following REST.

That is, of course, if you really are following REST, which means that you're building a hypermedia application. And while POST, PUT, and DELETE update resource state for hypermedia applications, every representation from resource back to client updates client state. Even a GET, which never changes resource state, still changes the application state. In other words, clicking a link or submitting a form loads a new page. Of course REST behaves that way.

While this article focused more on maintaining state on the client, therefore, REST is more concerned with updating state on the client. The real point here is that we have the luxury of choosing to maintain the state information we require while running an application whose state is supposed to change. Either way, hypermedia are the engine of application state.

Image source: bloggyboulga

About Jason Bloomberg
Jason Bloomberg is the leading expert on architecting agility for the enterprise. As president of Intellyx, Mr. Bloomberg brings his years of thought leadership in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture to a global clientele of business executives, architects, software vendors, and Cloud service providers looking to achieve technology-enabled business agility across their organizations and for their customers. His latest book, The Agile Architecture Revolution (John Wiley & Sons, 2013), sets the stage for Mr. Bloomberg’s groundbreaking Agile Architecture vision.

Mr. Bloomberg is perhaps best known for his twelve years at ZapThink, where he created and delivered the Licensed ZapThink Architect (LZA) SOA course and associated credential, certifying over 1,700 professionals worldwide. He is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in 2011. He now runs the successor to the LZA program, the Bloomberg Agile Architecture Course, around the world.

Mr. Bloomberg is a frequent conference speaker and prolific writer. He has published over 500 articles, spoken at over 300 conferences, Webinars, and other events, and has been quoted in the press over 1,400 times as the leading expert on agile approaches to architecture in the enterprise.

Mr. Bloomberg’s previous book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business (John Wiley & Sons, 2006, coauthored with Ron Schmelzer), is recognized as the leading business book on Service Orientation. He also co-authored the books XML and Web Services Unleashed (SAMS Publishing, 2002), and Web Page Scripting Techniques (Hayden Books, 1996).

Prior to ZapThink, Mr. Bloomberg built a diverse background in eBusiness technology management and industry analysis, including serving as a senior analyst in IDC’s eBusiness Advisory group, as well as holding eBusiness management positions at USWeb/CKS (later marchFIRST) and WaveBend Solutions (now Hitachi Consulting).

Web 2.0 Latest News
As this year comes to a close, let's take one last look at the most pervasive cloud computing trends -- including increased usage across the different cloud service models, the key business drivers and the impact of agile innovation strategies.

Cloud computing adoption has m...
Cloud computing seems to still be one of the reigning buzzwords in high-tech these days. Everything is either “in the cloud”, “powered by the cloud”, or some variation on the theme. I remember when hosted email was just that: hosted email. Today, such offerings are considered cloud off...
Last week as I was writing Amazon Declares War on VMware, VMware was preparing to announce the acquisition of a pro services team to aid in cloud migration (see coverage in CRN): VMware Acquires Professional Services Firm To Boost Cloud Migration, DevOps Expertise. You can get my thoug...
Many projected use cases for IoT won’t directly generate revenues. To achieve greater efficiency, companies are deploying IoT sensors internally throughout their organizations to optimize their use of everything from computer servers to lighting to HVAC systems to employee productivity...
Many workloads are already in the cloud: Most organizations today run at least some workloads in the cloud. For newer organizations, they will often run ALL of their workloads in the cloud. For cloud-based workloads, sending log data to a cloud-based logging provider is not quite as bi...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021




SYS-CON Featured Whitepapers
ADS BY GOOGLE