Related Topics: @CloudExpo, Java IoT, Microservices Expo, Cloud Security, @BigDataExpo, SDN Journal

@CloudExpo: Article

Bringing Intelligence to REST

The API Economy has nearly run its course.

Whether you're a Cloud Computing aficionado, an enterprise integration specialist, or an IT executive, it's hard to have a conversation today without mention of REST. Representational State Transfer, or REST to the cognoscenti, is an architectural style that treats distributed computing problems as though they were Web problems. On the Web you have browsers chatting via HTTP to Web servers, and those servers can work whatever magic they need to in order to serve up the full wealth we've all come to expect from the World Wide Web. Take those basic Web patterns, extend them to general distributed computing problems (including Cloud and legacy integration), and voila! You have REST.

However, while REST has achieved substantial success in simplifying software interfaces and thus facilitating many forms of integration, it is still inherently inflexible. What works well for humans using browsers often doesn't apply to arbitrary software clients. And most fundamentally, REST does not address the most difficult distributed computing challenge of all: how to deal with dynamic business context.

Freeing Ourselves from REST's Four Constraints
The majority of RESTafarians, as the aforementioned cognoscenti have so eloquently dubbed themselves, treat REST as an Application Programming Interface (API) style. After all, REST does call for a uniform interface, a requirement that in one fell swoop addresses many of the knottier problems of Web Services and other, more tightly coupled API styles that came before. Compared to the complexities of Web Service operations or object-oriented remote method calls, REST's uniform interface is the essence of simplicity. Furthermore, there's no question that REST's uniform interface requirement is at the heart of what analysts like to refer to as the API Economy.

But there is more to REST than a uniform interface. In fact, REST isn't an API style at all. It's an architectural style. As an architectural style, REST consists of a set of constraints on software architecture. In other words, feel free to follow what architectural rules you like, but if you want to follow REST you must comply with the following RESTful constraints:

  1. Separation of resources from representations
  2. Manipulation of resources by representations
  3. Self-descriptive messages
  4. Hypermedia as the engine of application state, or HATEOAS

Let's take a quick tour of these constraints to put them in plain language. In so doing, we'll also why REST fails to adequately address the problem of dynamic business context.

The first constraint is essentially the encapsulation requirement. Resources are abstractions of capabilities on a server, while the representations are what the resources provide to the client. For example, a resource might be a php script running on a Web server, and the representation might be an HTML file it returns when a browser makes a GET request of it. But the browser never, ever gets the php itself; it only sees the HTML. The php is forever hidden from view.

The second constraint calls for the uniform interface. The only way that clients are able to interact with resources is by following hyperlinks in representations - in other words, making GET, POST, PUT, or DELETE requests to the URI of the resource, assuming we're using HTTP as our transport protocol, which we usually are.

The third, self-descriptive message constraint is actually quite straightforward: all the data as well as all the metadata the resource needs to process a request must be contained in that request, and correspondingly, the resource must send all necessary metadata in the representation response to the client that the client will need to understand the representation. In other words, REST requires that there be no out-of-band metadata: information pertinent to the interaction that doesn't actually appear in the interaction. Furthermore, the interaction must be stateless: the resource isn't expected to keep track of any information pertinent to any particular client.

The problem with this third constraint, of course, is that out-of-band metadata is very handy in many situations. Take security-related metadata, for example. REST calls for all such metadata to be in every request, which led to the development of the OAuth (Open Authorization) standard. Yes, OAuth is quite powerful and Web friendly. Yes, OAuth is making inroads into the enterprise. But do you really want to restrict the security protocols for all of your interactions to OAuth and nothing but OAuth? Probably not.

If you have a more complex interaction than a simple request, then the ban on out-of-band metadata becomes increasingly impractical. For example, let's say you're trying to support a complex business process by building a composite application. You're trying to follow REST so you're composing resources. But then you find you need to somehow deal with a range of policies, business rules, or other out-of-band metadata that impact the behavior of your composite application for certain users but not others. REST alone simply doesn't deal well with such complexities.

And then there's the fourth constraint: the dreaded HATEOAS. REST separates state information into two types: resource state and application state. Resource state is shared or persisted state information on the server, while application state is specific to the individual client, who negotiates the application (think abstracted Web site) by following hyperlinks. The HATEOAS constraint hammers home the fact that the point of REST is building distributed hypermedia systems, where the client is responsible for running hypermedia-based applications. In other words, the hypermedia contain the business context for the interactions between client and server.

Hypermedia drive the Web, of course, but once you start breaking down REST's notions of client and server, however, then the power of hypermedia starts to wane. After all, enterprises often want to build or leverage business applications that offer more than a simple Web site, especially when there's a shared business context across nodes, where those nodes are more than just clients and servers. Hypermedia - and REST - simply weren't built for such complex, dynamic situations.

The Devil in the Details
There's a very good reason why REST eschews out-of-band metadata and shared business context beyond the scope of hypermedia: both of these requirements are inherently dynamic, and furthermore, depend upon multiple actors - actors who may change over time. By constraining the architecture to avoid such complexities, REST provides a useful set of simplifications that have provided unquestionable value throughout the API economy.

The challenges in the section above, however, go well beyond REST. The problems we're discussing have plagued software interfaces in general, from the earliest screen-scraping programs to object-oriented APIs to Web Services to today's RESTful APIs. The entire notion of a software interface is an agreement between the people building the software provider and consumer endpoints that the interface behaves a particular way. Loose coupling, after all, relies upon an interface contract that fixes the behavior of the API so that the parties involved can make various decisions about their software under the covers without breaking the interaction. But woe to those who dare to change the contract, or who want to consider metadata the contract knows nothing about!

Out-of-band metadata and business context outside hypermedia applications are by definition exterior to the contract, and thus aren't amenable to any distributed computing architectural style that relies too heavily on static APIs. Therein lies the essential challenge of the API. To those analysts trumpeting the API Economy I say: the API Economy has nearly run its course. We've solved as many problems as we're going to solve with contracted software interfaces. But the business stakeholders still aren't happy. After all, it's their context - the business context - that APIs (whether RESTful or not) are so woefully unable to deal with. It's time for another approach.

The EnterpriseWeb Take
I'm not saying that we don't need APIs, of course, or that REST doesn't serve a useful purpose. I am declaring, however, that something critically important is missing from this picture. APIs are far too static to address issues of dynamic business context. We tried to address these issues with the SOA intermediary (typically an ESB), where the intermediary executed policy-based routing and transformation rules to abstract a set of inflexible Service interfaces, thus providing the illusion of flexibility, much as a flip deck provides the illusion of motion. But even the most successful implementers of SOA were still unable to deal with most out-of-band metadata - and dynamic business context? That nut no one has been able to crack.

What we really need is an entirely different kind of intermediary. A smarter intermediary that knows how to deal with all types of metadata and furthermore, can resolve the more difficult challenge of business context - in real time, where the business lives. In the next issue of Loosely-Coupled I'll discuss how such a smarter intermediary might actually work. And naturally, if you want to see one in action, drop us a line.

Image credit: lin440315

More Stories By 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).

Latest Stories
DevOps theory promotes a culture of continuous improvement built on collaboration, empowerment, systems thinking, and feedback loops. But how do you collaborate effectively across the traditional silos? How can you make decisions without system-wide visibility? How can you see the whole system when it is spread across teams and locations? How do you close feedback loops across teams and activities delivering complex multi-tier, cloud, container, serverless, and/or API-based services?
Today every business relies on software to drive the innovation necessary for a competitive edge in the Application Economy. This is why collaboration between development and operations, or DevOps, has become IT’s number one priority. Whether you are in Dev or Ops, understanding how to implement a DevOps strategy can deliver faster development cycles, improved software quality, reduced deployment times and overall better experiences for your customers.
In the 21st century, security on the Internet has become one of the most important issues. We hear more and more about cyber-attacks on the websites of large corporations, banks and even small businesses. When online we’re concerned not only for our own safety but also our privacy. We have to know that hackers usually start their preparation by investigating the private information of admins – the habits, interests, visited websites and so on. On the other hand, our own security is in danger bec...
The Internet of Things (IoT), in all its myriad manifestations, has great potential. Much of that potential comes from the evolving data management and analytic (DMA) technologies and processes that allow us to gain insight from all of the IoT data that can be generated and gathered. This potential may never be met as those data sets are tied to specific industry verticals and single markets, with no clear way to use IoT data and sensor analytics to fulfill the hype being given the IoT today.
Enterprises have been using both Big Data and virtualization for years. Until recently, however, most enterprises have not combined the two. Big Data's demands for higher levels of performance, the ability to control quality-of-service (QoS), and the ability to adhere to SLAs have kept it on bare metal, apart from the modern data center cloud. With recent technology innovations, we've seen the advantages of bare metal erode to such a degree that the enhanced flexibility and reduced costs that cl...
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his session at @DevOpsSummit 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will show how customers are able to achieve a level of transparency that enables everyon...
Donna Yasay, President of HomeGrid Forum, today discussed with a panel of technology peers how certification programs are at the forefront of interoperability, and the answer for vendors looking to keep up with today's growing industry for smart home innovation. "To ensure multi-vendor interoperability, accredited industry certification programs should be used for every product to provide credibility and quality assurance for retail and carrier based customers looking to add ever increasing num...
“Media Sponsor” of SYS-CON's 19th International Cloud Expo, which will take place on November 1–3, 2016, at the Santa Clara Convention Center in Santa Clara, CA. CloudBerry Backup is a leading cross-platform cloud backup and disaster recovery solution integrated with major public cloud services, such as Amazon Web Services, Microsoft Azure and Google Cloud Platform.
In the next forty months – just over three years – businesses will undergo extraordinary changes. The exponential growth of digitization and machine learning will see a step function change in how businesses create value, satisfy customers, and outperform their competition. In the next forty months companies will take the actions that will see them get to the next level of the game called Capitalism. Or they won’t – game over. The winners of today and tomorrow think differently, follow different...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, will discuss how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team a...
@DevOpsSummit has been named the ‘Top DevOps Influencer' by iTrend. iTrend processes millions of conversations, tweets, interactions, news articles, press releases, blog posts - and extract meaning form them and analyzes mobile and desktop software platforms used to communicate, various metadata (such as geo location), and automation tools. In overall placement, @DevOpsSummit ranked as the number one ‘DevOps Influencer' followed by @CloudExpo at third, and @MicroservicesE at 24th.
The security needs of IoT environments require a strong, proven approach to maintain security, trust and privacy in their ecosystem. Assurance and protection of device identity, secure data encryption and authentication are the key security challenges organizations are trying to address when integrating IoT devices. This holds true for IoT applications in a wide range of industries, for example, healthcare, consumer devices, and manufacturing. In his session at @ThingsExpo, Lancen LaChance, vic...
Regulatory requirements exist to promote the controlled sharing of information, while protecting the privacy and/or security of the information. Regulations for each type of information have their own set of rules, policies, and guidelines. Cloud Service Providers (CSP) are faced with increasing demand for services at decreasing prices. Demonstrating and maintaining compliance with regulations is a nontrivial task and doing so against numerous sets of regulatory requirements can be daunting task...
What are the successful IoT innovations from emerging markets? What are the unique challenges and opportunities from these markets? How did the constraints in connectivity among others lead to groundbreaking insights? In her session at @ThingsExpo, Carmen Feliciano, a Principal at AMDG, will answer all these questions and share how you can apply IoT best practices and frameworks from the emerging markets to your own business.
Between the mockups and specs produced by analysts, and resulting applications built by developers, there exists a gulf where projects fail, costs spiral, and applications disappoint. Methodologies like Agile attempt to address this with intensified communication, with partial success but many limitations. In his session at @DevOpsSummit at 19th Cloud Expo, Charles Kendrick, CTO at Isomorphic Software, will present a revolutionary model enabled by new technologies. Learn how business and deve...