Welcome!

Cloud Expo Authors: Liz McMillan, Elizabeth White, Cloud Ventures, Pat Romanski, Michelle Drolet

Related Topics: SOA & WOA, Java, .NET, Web 2.0, Cloud Expo, Apache

SOA & WOA: Article

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

More Stories By Jason Bloomberg

Jason Bloomberg is Chief Evangelist at EnterpriseWeb, where he drives the message and the community for EnterpriseWeb’s next generation enterprise platform. He is a global thought leader in the areas of Cloud Computing, Enterprise Architecture, and Service-Oriented Architecture. He is a frequent conference speaker and prolific writer, and he also serves as blogger for DevX. His latest book, The Agile Architecture Revolution: How Cloud Computing, REST-based SOA, and Mobile Computing are Changing Enterprise IT (John Wiley & Sons), was published in March 2013. Prior to EnterpriseWeb he was President of ZapThink, where he created the Licensed ZapThink Architect (LZA) SOA course and associated credential, and ran the LZA course as well as his Enterprise Cloud Computing course around the world. He was also the primary contributor to the ZapFlash newsletter and blog for twelve years. Mr. Bloomberg is one of the original Managing Partners of ZapThink LLC, the leading SOA advisory and analysis firm, which was acquired by Dovel Technologies in August 2011. Mr. Bloomberg’s 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). He has 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).

Cloud Expo Breaking News
More and more enterprises today are doing business by opening up their data and applications through APIs. Though forward-thinking and strategic, exposing APIs also increases the surface area for potential attack by hackers. To benefit from APIs while staying secure, enterprises and security architects need to continue to develop a deep understanding about API security and how it differs from traditional web application security or mobile application security. In his session at 14th Cloud Expo, Sachin Agarwal, VP of Product Marketing and Strategy at SOA Software, will walk you through the various aspects of how an API could be potentially exploited. He will discuss the necessary best practices to secure your data and enterprise applications while continue continuing to support your business’s digital initiatives.
The revolution that happened in the server universe over the past 15 years has resulted in an eco-system that is more open, more democratically innovative and produced better results in technically challenging dimensions like scale. The underpinnings of the revolution were common hardware, standards based APIs (ex. POSIX) and a strict adherence to layering and isolation between applications, daemons and kernel drivers/modules which allowed multiple types of development happen in parallel without hindering others. Put simply, today's server model is built on a consistent x86 platform with few surprises in its core components. A kernel abstracts away the platform, so that applications and daemons are decoupled from the hardware. In contrast, networking equipment is still stuck in the mainframe era. Today, networking equipment is a single appliance, including hardware, OS, applications and user interface come as a monolithic entity from a single vendor. Switching between different vendor'...
You use an agile process; your goal is to make your organization more agile. What about your data infrastructure? The truth is, today’s databases are anything but agile – they are effectively static repositories that are cumbersome to work with, difficult to change, and cannot keep pace with application demands. Performance suffers as a result, and it takes far longer than it should to deliver on new features and capabilities needed to make your organization competitive. As your application and business needs change, data repositories and structures get outmoded rapidly, resulting in increased work for application developers and slow performance for end users. Further, as data sizes grow into the Big Data realm, this problem is exacerbated and becomes even more difficult to address. A seemingly simple schema change can take hours (or more) to perform, and as requirements evolve the disconnect between existing data structures and actual needs diverge.
Cloud backup and recovery services are critical to safeguarding an organization’s data and ensuring business continuity when technical failures and outages occur. With so many choices, how do you find the right provider for your specific needs? In his session at 14th Cloud Expo, Daniel Jacobson, Technology Manager at BUMI, will outline the key factors including backup configurations, proactive monitoring, data restoration, disaster recovery drills, security, compliance and data center resources. Aside from the technical considerations, the secret sauce in identifying the best vendor is the level of focus, expertise and specialization of their engineering team and support group, and how they monitor your day-to-day backups, provide recommendations, and guide you through restores when necessary.
Cloud scalability and performance should be at the heart of every successful Internet venture. The infrastructure needs to be resilient, flexible, and fast – it’s best not to get caught thinking about architecture until the middle of an emergency, when it's too late. In his interactive, no-holds-barred session at 14th Cloud Expo, Phil Jackson, Development Community Advocate for SoftLayer, will dive into how to design and build-out the right cloud infrastructure.
SYS-CON Events announced today that SherWeb, a long-time leading provider of cloud services and Microsoft's 2013 World Hosting Partner of the Year, will exhibit at SYS-CON's 14th International Cloud Expo®, which will take place on June 10–12, 2014, at the Javits Center in New York City, New York. A worldwide hosted services leader ranking in the prestigious North American Deloitte Technology Fast 500TM, and Microsoft's 2013 World Hosting Partner of the Year, SherWeb provides competitive cloud solutions to businesses and partners around the world. Founded in 1998, SherWeb is a privately owned company headquartered in Quebec, Canada. Its service portfolio includes Microsoft Exchange, SharePoint, Lync, Dynamics CRM and more.
The world of cloud and application development is not just for the hardened developer these days. In their session at 14th Cloud Expo, Phil Jackson, Development Community Advocate for SoftLayer, and Harold Hannon, Sr. Software Architect at SoftLayer, will pull back the curtain of the architecture of a fun demo application purpose-built for the cloud. They will focus on demonstrating how they leveraged compute, storage, messaging, and other cloud elements hosted at SoftLayer to lower the effort and difficulty of putting together a useful application. This will be an active demonstration and review of simple command-line tools and resources, so don’t be afraid if you are not a seasoned developer.
SYS-CON Events announced today that BUMI, a premium managed service provider specializing in data backup and recovery, will exhibit at SYS-CON's 14th International Cloud Expo®, which will take place on June 10–12, 2014, at the Javits Center in New York City, New York. Manhattan-based BUMI (Backup My Info!) is a premium managed service provider specializing in data backup and recovery. Founded in 2002, the company’s Here, There and Everywhere data backup and recovery solutions are utilized by more than 500 businesses. BUMI clients include professional service organizations such as banking, financial, insurance, accounting, hedge funds and law firms. The company is known for its relentless passion for customer service and support, and has won numerous awards, including Customer Service Provider of the Year and 10 Best Companies to Work For.
Chief Security Officers (CSO), CIOs and IT Directors are all concerned with providing a secure environment from which their business can innovate and customers can safely consume without the fear of Distributed Denial of Service attacks. To be successful in today's hyper-connected world, the enterprise needs to leverage the capabilities of the web and be ready to innovate without fear of DDoS attacks, concerns about application security and other threats. Organizations face great risk from increasingly frequent and sophisticated attempts to render web properties unavailable, and steal intellectual property or personally identifiable information. Layered security best practices extend security beyond the data center, delivering DDoS protection and maintaining site performance in the face of fast-changing threats.
From data center to cloud to the network. In his session at 3rd SDDC Expo, Raul Martynek, CEO of Net Access, will identify the challenges facing both data center providers and enterprise IT as they relate to cross-platform automation. He will then provide insight into designing, building, securing and managing the technology as an integrated service offering. Topics covered include: High-density data center design Network (and SDN) integration and automation Cloud (and hosting) infrastructure considerations Monitoring and security Management approaches Self-service and automation
In his session at 14th Cloud Expo, David Holmes, Vice President at OutSystems, will demonstrate the immense power that lives at the intersection of mobile apps and cloud application platforms. Attendees will participate in a live demonstration – an enterprise mobile app will be built and changed before their eyes – on their own devices. David Holmes brings over 20 years of high-tech marketing leadership to OutSystems. Prior to joining OutSystems, he was VP of Global Marketing for Damballa, a leading provider of network security solutions. Previously, he was SVP of Global Marketing for Jacada where his branding and positioning expertise helped drive the company from start-up days to a $55 million initial public offering on Nasdaq.
Performance is the intersection of power, agility, control, and choice. If you value performance, and more specifically consistent performance, you need to look beyond simple virtualized compute. Many factors need to be considered to create a truly performant environment. In his General Session at 14th Cloud Expo, Marc Jones, Vice President of Product Innovation for SoftLayer, will explain how to take advantage of a multitude of compute options and platform features to make cloud the cornerstone of your online presence.
Hybrid cloud refers to the federation of a public and private cloud environment for the purpose of extending the elastic and flexibility of compute, storage and network capabilities, in an on-demand, pay-as-you go basis. The hybrid approach allows a business to take advantage of the scalability and cost-effectiveness that a public cloud computing environment offers without exposing mission-critical applications and data to third-party vulnerabilities. Hybrid cloud environments involve complex management challenges. First, organizations struggle to maintain control over the resources that lie outside of their managed IT scope. They also need greater infrastructure visibility to help reduce maintenance costs and ensure that their company data and resources are properly handled and secured.
Are you interested in accelerating innovation, simplifying deployments, reducing complexity, and lowering development costs? The cloud is changing the face of application development and deployment, with enterprise-grade infrastructure and platform services making it possible for you to build and rapidly scale enterprise applications. In his session at 14th Cloud Expo, Gene Eun, Sr. Director, Oracle Cloud at Oracle, will discuss the latest solutions and strategies for application developers and enterprise IT organizations to leverage Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) to build and deploy modern business applications in the cloud.
As more applications and services move "to the cloud" (public or on-premise), cloud environments are increasingly adopting and building out traditional enterprise features. This in turn is enabling and encouraging cloud adoption from enterprise users. In many ways the definition is blurring as features like continuous operation, geo-distribution or on-demand capacity become the norm. At NuoDB we're involved in both building enterprise software and using enterprise cloud capabilities. In his session at 14th Cloud Expo, Seth Proctor, CTO of NuoDB, Inc., will cover experiences from building, deploying and using enterprise services and suggest some ways to approach moving enterprise applications into a cloud model.