if #REST was ... #iLikeThisGame
yesterday,
Erik Wilde posted an
excellent tweet:
if #REST was a data transfer method, it would be called REDT. your database is not your application.
i like it because it cuts right to the heart of common thinking about "Fielding's REST" - that it follows the common data-driven paradigm for publishing content on the Web.
but, it turns out, Fielding's dissertation it not at all about data or even about "the Web." instead his work is about network-based software architectures. much less "entertaining" a topic than most are willing to deal with.
so folks like Erik are right to help steer the conversation about REST away from common patterns and toward a more inclusive view of how architectural styles influence the way we all implement solutions on the Web.
but...
i rather rudely hijacked Erik's twhead (that's a twitter thread, BTW) and used it make some additional points about both REST and the way people 'think' about it.
if #REST was an object transfer method...
if #REST was... an object transfer method, it would be called ROT; your object graph is not your application.
i see this way too often. many frameworks and libraries lead unsuspecting devs down this "not-so-happy-path", too. converting private internal objects into public messages to send over the Web is a bad idea. first, it exposes way too much of your internal works; much like exposing your data model does. second, it creates brittle dependencies between client and server based on a static object model; limiting the possibilities for evolving and extending the model in the future. finally, it requires all parties who want to deal with the server to "understand" that server's object model; even to the point of "understanding" the quirks and subtleties of that server's particular serialization framework.
"your object graph is not your application."
if #REST was a file transfer method...
If #REST was... a file transfer method, it would be called FTP; your file system is not your application.
this is a cheap shot, but i figured it needed to be said anyway. some (not many) view building solutions for the web as basically creating folders and files on a server disk and eachoing that files system image to the world. it works, of course; in fact it works very well. Web editors and HTTP servers do a great job of making static files available as public content; that's a 'good thing.'
the trouble starts, however, when the same folks publishing the layout of their server hard disks get tricked into thinking they are implementing an 'architectural style' in the Fielding tradition. of course, that's not the case. just as photo-copying paintings by Picasso and posting them in your office does not mean you are a 'painter' in the Picasso tradition.
"your file system is not your application."
if #REST was a way to transfer representations of transient state...
if #REST was... a way to transfer representations of transient state around, it'd be called.. hmm.. #iLikeThisGame
now we're getting somewhere! in fact, REST *is* a way to transfer representations of transient state!
but that's not very 'sexy' is it? it's pretty tough to market that idea, eh? it's even a challenge to get the concept into a tweet[grin]. and "ay, there's the rub."
Fielding's invention foucses on the value of reducing code dependence across the network by defining an incredibly limited network interface - one that *everyone* needs to agree to - and forcing parties to agree to a well-defined set of message formats; formats that carry not just data, but also include "affordances" which provide choices for "next steps" along the way:
Distributed hypermedia provides a uniform means of accessing services through the embedding of action controls within the presentation of information retrieved from remote sites.
as i mentioned in a previous blog post, i have yet to find a single framework which adopt this (still radical after more than a decade) notion of "embedding of action controls within the presentation of information" as a fundamental aspect of Web implementation mechanics.
i like this game!
i must admit, Erik has hit on an excellent approach. i like it so much i co-opted it and kinda pushed Erik's original point out the door; sorry, friend.
but Erik's point remains: your data model is not your app. one of the reasons he may be talking about this issue is that Erik is co-chair of the Linked Data Platform Working Group. he is likely deep in the process of helping folks grasp the notion that the data-model is not the only basis for an successful architectural style for the Web.
and that's a 'good thing.'