representin'
HTTP is the only
application-level protocol I know of that
relies on the concept of "representations" as the primary way to transfer
information between parties.
discovery
i find myself repeating the above phrase relatively often lately. i noticed this aspect of HTTP many years ago. it greatly affected my thinking about the methodologies to employ when implementing solutions on the Web. once i grasped the notion that Web communications could exist at the abstraction of negotiable representations, a entirely new set of possiblities for improving the quality of communication were available to me.
but then...
realization
i quickly realized that most of the frameworks and other tooling at my disposal when building Web solutions ignores this level of abstraction. IOW, while i have easy access to private component objects and data elements and a well-established pattern for exposing these private objects to the public (Serialization), there are few common frameworks that make it easy to represent my private component details in one of the dozens of domain- and framework-agnostic registered media types designed for this very purpose.
that means, each time i want to craft a representation of my private object to share on the public Web, i need to "hand-roll" my representation layers. to me, while annoying, i assumed that this was the price i had to pay in order to maintain the SoC on the public Web that would allow me to safely interact w/ a wide range of clients and servers over time.
i also assumed others took the same POV; that they, too, felt this pain and would (eventually) prod frameworks and tool providers to "add-in" support for the representation-level abstraction.
but then...
discovery
it dawned on me (as i travelled around speaking, writing, and learning) that most devs i encountered didn't see things the same way i did. instead of "pining" for the SoC of representation abstractions, most devs simply accepted the status quo and assumed exposing private objects via serialization (and the perpetual wrestling match of keeping client object models and server object models in sync over time) was more than the norm, it was "the way to do things on the Web." in addition, to my chagrin, when i took the time to point out HTTP's representation abstraction most devs either denied it's usefulness and/or decried it's implementation details as too complex to be worth the effort.
few of those i spoke to even suggested that frameworks and tools should 'level up' and include proper support for the representation abstraction inherent in HTTP in order to remove these artifical barriers to improved communication options on the Web.
so...
realization
i concluded that it is important to continue to write about. and advocate for, increased support for representation abstraction in Web tooling. i am pleased to see evidence of increased use of representations in implementations, too (check the trending download count over time on the very solid mimeparse project). i'm happy to see popular frameworks adopting representation-as-a-pattern and it's good to see at least one framework adopting support for the representation abstraction.
but there is more work to be done...
discovery
as more people discover the power and possibility of representing domain-specific information in an implementation-agsnotic way, more Web solutions will exhibit the reusability, extensibility, and evolvability (among other things) that can result when implementing distributed solutions for the Web. IMO, the "new" trend of Web APIs will succeed (or fail) largely on the ability of tooling to support HTTP's representation abstraction.
realization
how well does your current set of frameworks and tools handle HTTP's representation abstraction?