This guest post comes from Mike Amundsen, Principal API Architect at Layer 7 Technologies, accomplished author and co-creator of the annual REST Fest Unconference. You can follow Mike on Twitter at @mamund.
As the number of mobile devices increases and the trend toward native apps continues, enterprises face new challenges in effectively deploying flexible, scalable and secure APIs. When you have millions of users – each with an installed version of your app – every change that requires an updated download can result in lots of “unproductive” time. And that doesn’t even include the time spent (re)coding, testing and deploying each update. Multiply this process by the tens of thousands of mobile apps in various app stores and you get a sense of the size of the problem; and all indications are it will get worse before it gets better.
What’s the solution? Stop improving functionality for existing apps? Stop releasing so many apps? Limit the number of users of these apps? Engineer incredibly efficient patching over the Internet? How about none of the above.
This problem is not new. In the 1990s, Virtual Machines (i.e. Java, .NET, etc.) emerged as a way to combat the expense of compiling to multiple desktop environments. Around the same time a PhD graduate student at UC Irvine, seeing this trend, offered an even more radical solution for Web-based applications. He proposed a solution aimed at designing-in the ability of client applications to provide new features and functionality without the need for re-installs at all. This solution works on any server platform and client OS, too. That student was Roy T. Fielding, and the solution he proposed is called REpresentational State Transfer (REST).
While most people discussing REST focus on its use of URIs and HTTP methods, one of the fundamental contributions Fielding made in his work is the addition of hypermedia as a design element. Instead of hard-coding client applications to know ahead of time about all the possible remote calls, all the possible arguments and the order in which they must be executed, Fielding created a model where this information is supplied to the client in a machine-readable form at runtime within server responses.
This subtle shift in the source of application control information makes it possible for the same client code to recognize and execute new features as they appear over time without the need for patches or downloads. The common Web browser is a limited version of this approach. It’s the Web client’s ability to leverage hypermedia messages that makes it possible to use the same browser to perform diverse tasks like banking and content-editing even while running games, all without the need for specific install routines for each application.
Even though the REST architectural style was officially published more than a decade ago, there are still not very many examples of Fielding’s hypermedia approach to creating enterprise-level APIs. Part of the reason is that his model is very different from most architectural styles used in the enterprise today. Instead of relying on object-oriented paradigms on the network, Fielding’s model focuses on transferring the changing “state” of an application between client and server using a very limited set of procedures (less than ten possible functions) and a semantically rich message format (technically called a media type).
System architects are rarely exposed to this approach to modeling problem domains. There are currently no mainstream tools to help model domains and then “translate” business processes into a Fielding-style RESTful system.
The good news is that this is changing. More architects are recognizing the advantages of Fielding’s style and are starting to build systems focused on using rich messages to communicate data AND information about how clients can “talk” to servers using hypermedia controls embedded in the response.
But even when system architects model RESTful systems, developers face hurdles attempting to bring them to life. Similar to the problem faced by system architects, developers lack the tooling for implementing hypermedia systems. Currently there is no well-known “Hypermedia development platform.” That means developers often need to “roll their own” tools and helper libraries in order to make hypermedia implementation less tedious and error-prone.
Developers are also in need solid guidance and training in implementing hypermedia-style systems. While there are many blogs and several books with “REST” in the title, not many of them focus on Fielding’s critical hypermedia component. Instead they contain details on using the HTTP protocol and guidance on translating object-oriented models into familiar remote procedure call (RPC) interfaces similar to those written before Fielding proposed his message-based REST style.
Despite these challenges, evidence of the change from RPC-style to Hypermedia-style APIs is starting to appear within enterprise shops. For example, auto insurance giant GEICO is working with the Hypertext Application Language (HAL) format to build hypermedia-driven services. Ecommerce provider ElasticPath (based in Vancouver, BC) is currently rolling out a new hypermedia API based on their own message design. And Comcast, the largest cable operator in the United States, is using hypermedia-style machine-to-machine APIs that are also “surfable” and testable using common Web browsers.
These companies and others are adopting hypermedia as a way to improve the flexibility and scalability of both their internal and public APIs. Some see hypermedia-style APIs as a market differentiator and strategic advantage, too. While it is too early to draw definitive conclusions, it’s a good bet they will not be alone in this trend and, if documented success is achieved, others will follow in their footsteps.