how to spot a hypermedia client app
it's not always easy to spot hypermedia clients 'in the wild.' there are a handful of reasons for this. however, if you know what you're looking for, it is actually pretty straight-forward to ferret out the real hypermedia clients from the posers.
appearances can be deceiving
you can't usually spot a hypermedia client from the 'outside.' it's not
the way the app looks or feels that indicates true hypermedia. for example,
some folks think implementing an HTML-based app is the same as implementing
a hypermedia app. but, sorry, no. an HTML app can be a couple
some think that Web apps which exhibit adaptability are hypermedia clients. not necessarily. you can achieve a great deal of flexibility and adaptability through the use of configuration (including remote configuration) and support for plug-ins or dynamically loaded modules based on configuration or user context (e.g. which user is logged in, what they are allowed to access, etc.).
this is all good stuff, but it's not a sure sign of hypermedia use.
server API is not enough
it might seem that any server that emits a hypermedia-style API would
result in hypermedia clients. but, no, that's not right either. in fact,
one of the features of hypermedia implementation is that servers don't
dictate how clients use their interfaces. servers merely respond with
machine-readable descriptions of links (e.g.
atom.link, etc.) and
and let client apps decide what to do with them (if anything).
it's very easy to build successful client applications that 'talk' to hypermedia interfaces on servers yet still ignore the inline affordances and just deal the content in which the client app is interested. they can even ignore all the hypermedia and 'memorize' URLs, workflow paths, etc. and continue to work fine with the server.
until, of course, the server changes the rules. then client apps that ignore the hypermedia run the risk of misbehaving or even breaking.
it's what's inside that counts
it turns out there is a rather simple way to spot hypermedia clients - look 'inside.' this is especially easy for browser-based hypermedia apps. a quick "View Source" will almost always reveal the level to which the application is tuned to hypermedia instead of a pre-determined set of data and actions.
imagine a simple service (
TASKS) that tracks "to-do" tasks. it might, for example,
support a small set of data and actions:
id- unique identifier data element
text- a string that describes the task to complete
LIST- an action that returns the list of tasks
FILTER- an action that returns a subset of items, filtered by title fragment
ADD- an action that creates a new task in the list
MARK-COMPLETE- an action that marks an existing tasks complete
now, without getting tied up in the server interface (we'll assume the server responds w/ inline hypermedia), we can check out client-side source code and spot which client app is actually relying on inline hypermedia.
below is a listing of the functions and shared variables from one client
app using this
TASKS service. do you think this is a hypermedia
not sure? how about this next one?
one of these clients has 'memorized' quite a bit about the
service and the other has very little foreknowledge of how things work
TASKS service. that means one of these clients has a better
chance of handling changes to the service workflow and data elements and the other
one has a high dependency on the service specifics and will run into trouble when
those specifics change over time.
focus on inner beauty
both these client apps really exist. you can find the full source
code for a
TASKS service in the
API Academy repo
at github. both clients are fully functional and at runtime, from the outside, you can't
client from the
however, spotting hypermedia clients is straight-forward when you know what to look for. and knowing what to look for can help you when it comes time to create your own hypermedia client apps. in the end, you need to focus on keeping details out of the client code including the specifics of current data elements and workflow rules. instead, you can let the server interface fill those in for you at runtime. when you do that, the structure of your client will become simpler and easier to maintain.
and that's when you may begin to see an 'inner beauty' to hypermedia client apps that you might not have recognized in the past.