In my last blog post, I made the presumably controversial claim that Representational State Transfer (REST) wasn’t about building APIs. Rather, REST is an architectural style for building distributed hypermedia applications. So, what’s special about those?
Hypermedia is simply an update to the notion of hypertext: text files with hyperlinks to other text files, only now instead of just text, we have any number of different media types: images, videos, XML files, SVG files, etc. A hypermedia application is essentially a set of media representations interconnected by hyperlinks: think any modern Web site. A distributed hypermedia application, then, is a collection of one or more Web sites (running on potentially many different servers) interconnected via hyperlinks–which is really no different from one big Web site, if you think about it.
What makes this type of application special actually boils down to the prefix hyper. What makes a link a hyperlink is that it could link anywhere, even outside your sphere of control.
Remember your first menu-driven interface, perhaps on a green screen mainframe terminal? Click on the menu entries and another screen loads. Those menu entries were links, but they weren’t hyperlinks, because you remained within the same closed application. As a result, it didn’t matter how proprietary the technology was.
In contrast, what made the Web what it is today was the power of the hyperlink. It didn’t matter who controlled the page (or other media representation) you hyperlinked to, you could hyperlink there just the same.
Now, look at today’s enterprise applications, say your favorite ERP app. Which application is it more like: the green screen mainframe app of yesteryear, or the Web itself? I’m not asking here if that ERP app has a Web interface. I’m asking if it’s a collection of hyperlinked media representations with no central point of control.
Chances are, if it’s a traditional enterprise app, it has a single point of control. After all, your corporate data are in there! Of course you’re in charge of the app! But that’s not the way the Web is supposed to work – or any other app that is built to take advantage of the architectural constraints that define the way the Web works.
For those apps you need REST. Because that’s all that REST is: an architectural style for building distributed hypermedia apps. If you don’t want that kind of app, then don’t use REST.
