mca blog

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 DIV containers and thousands of lines of javascript; that's not hypermedia.

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. HTML.A, atom.link, etc.) and forms (e.g. HTML.FORM, collection.template, etc.) 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:

1. id - unique identifier data element
2. text - a string that describes the task to complete
3. LIST - an action that returns the list of tasks
4. FILTER - an action that returns a subset of items, filtered by title fragment
5. ADD - an action that creates a new task in the list
6. 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 client app?

not sure? how about this next one?

one of these clients has 'memorized' quite a bit about the TASKS service and the other has very little foreknowledge of how things work with the 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 CRUD implementation and a Hypermedia implementation of the TASKS service in the API Academy repo at github. both clients are fully functional and at runtime, from the outside, you can't tell the CRUD client from the Hypermedia client.

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.