Posted on 08-01-2014
I’m still gathering all of my thoughts on the hypermedia media panel this last week at API Craft. I have an Evernote full of ideas, thoughts, and potential stories from the amazing API event this week in Detroit. First up is responding to the Twitter backchannel around being a hypermedia hater, and the panel I moderated on Monday between Mike Amundsen (@mamund), Mike Kelly (@mikekelly85), Steve Klabnik (@steveklabnik), Kevin Swiber (@kevinswiber), Jørn Wildt (@JornWildt), and Markus Lanthaler (@MarkusLanthaler).
After bringing the panelists up, giving them each 10 minutes to introduce themselves, I kicked off the discussion by calling out a Tweet from @JeremiahLee:
First, I called out @JeremiahLee because he happened to tweet right at the moment I was moderating the panel, and second because I thought his comment reflected the polarization of the conversation around hypermedia. I personally know @JeremiahLee, and I know he’s not a hater, he a super smart, and critical leader in the API conversation, but he Tweeted a controversial tweet, at the perfect moment, and I seized the opportunity. ;-)
Hypermedia hating was a central theme to the event in Detroit, and I have several stories planned, hoping to further explore the phenomena, and make suggestions for moving the conversation forward, and @JeremiahLee provided a little more explanation of himself, so let’s explore his position, and I'll add some commentary along the way:
Thank you so much for Tweeting this @JeremiahLee, it really did provide a great focal point for kicking off the panel, and made this topic be a pervasive part of the conversation across the next two days! ;-)
It’s not being a hater to demand people articulate well researched problems before proposing solutions. #APICraft 2/7— Jeremiah Lee (@JeremiahLee) July 29, 2014
Very true, but you can when you call someone’s conversation about a proposed solution, 99% bullshit. ;-) Something I think is a hallmark of many of the hypermedia haters, which immediately makes it easy to label as such, from a single Tweet.
It’s not being a hater to expect a solution be less painful than the problem being solved. #APICraft 3/7— Jeremiah Lee (@JeremiahLee) July 29, 2014
Spot on, and something the hypermedia has failed to do. I do see signs where the benefits are being demonstrated, and potentially outweigh the work involved, but they are poorly communicated. There is so much work to be done on educating people around what hypermedia even is, let alone demonstrating the solutions it provides, which will allow each person to individually assess whether it alleviates more pain then it creates, and is something they should consider.
I want to see how hypermedia can reduce integration time and frustration. I want to see how it prevents clients from breaking. #APICraft 4/7— Jeremiah Lee (@JeremiahLee) July 29, 2014
Great feedback. I think this was heard loud and clear by the audience. They realize there is a lot of work to be done to increase the number hypermedia API implementations in the wild, which will result in better client tooling, which will also provide material for the stories and evidence you will need to satisfy this concern.
Linking data is cool. Finding common ways to describe common data types can enable some use cases. Do we need the rest? #APICraft 5/7— Jeremiah Lee (@JeremiahLee) July 29, 2014
Another area that was discussed at the event. I think HAL provides a minimalist approach that fits this description, and I leave to each of the other hypermedia format designers to chime in on why their approach is preferred, and isn’t extraneous baggage. I will also spend some time better acquainting myself with each of the formats, and try to lend my own view. I think linking data, and establishing a common data vocabulary are great starting points for demonstrating hypermedia value to API providers and consumers, and we will have to build a case for each addition layer added on from there--lots of work to be done!
I’m not convinced the problems being talked about are wide spread or painful enough to warrant much overhead. #APICraft 6/7— Jeremiah Lee (@JeremiahLee) July 29, 2014
I agree, and we need to see stories of specific implementations, that demonstrate that more value is generated then pain, as I said above. I’d also urge you to look beyond just pain, and looking at the potential for establish new ways to express ourselves using APIs. I think hypermedia can provide very subtle, simple ways of expression that don’t impose a lot of overhead, but can make integration, and even the end-user experience much smoother, chipping off the rough edges of what we currently have, reducing pain incrementally as we go.
I’m not convinced the hypermedia solutions can live up to the bold claims that border on magic. #APICraft 7/7— Jeremiah Lee (@JeremiahLee) July 29, 2014
The conversations I heard over the three days of API Craft do not reflect the “bold claims” I hear of online. I did not hear talk of a perfect API client, or APIs that never break, and the other “magic” that is pointed at in online discussions. The conversations were very humble, realistic, and talked of the challenges, pitfalls, and acknowledging hypermedia is not a fit for all scenarios. While I’m sure there are some snake oil hypermedia practitioners who preach magic, but I’m thinking “magic” and “bullshit” are the terms used by folks who aren’t immersing themselves in the conversations around hypermedia, and will only change when there is more material to help onboard them, and demonstrate real world implementations, and the solutions they provide.
I’d have to put the term bulldozers in the same toolbox as bullshit, and magic. By no means do I see adding simple linking at the bottom of an API response as a bulldozer. I saw many layers to what hypermedia is, and I think calling it a bulldozer is speaking to the entire stack, not acknowledging providers can implement any part, and developers can also choose to use or ignore any part, as well.
I will explore more of these thoughts in future posts on hypermedia, but I wanted to respond specifically to @JeremiahLee thoughts. You do have some excellent points @JeremiahLee, and I think they were heard loud and clear, and reflect the conversation that happened throughout API Craft. I think for anyone who wants to refrain from being labeled a hater, when it comes to REST, hypermedia, or any other topic, should be cautious when using polarizing terminology, and encourage the community to produce more of the evidence you are requiring to make the leap--while also acknowledging their desire to pioneer into new areas, which is good for entire community.
I will do my part to continue producing stories about what hypermedia is, and provide more examples of where hypermedia is being applied. I’m paying attention to hypermedia in 2014, not because it is the latest trend, I’m paying attention to it because in my monitoring of the API space I’m seeing a significant amount of discussion around it beyond just the academic discussions on API Craft. I’m seeing an increased amount of blog posts, and examples of hypermedia being used in the wild.
Thanks for playing so nicely into the discussion on hypermedia at API Craft, Jeremiah. I think you are asking the right questions, I just want to help both sides of the discussion better understand how we can better set the tone for the conversation, so that things are more productive, and the whole community can move forward in a healthy way.
comments powered by Disqus
Winning in the API Economy
|Download as PDF|
Latest Blog Posts
- Swagger Visualization Layer Using D3.js
- Establishing Common Dictionaries That Industries Can Use In Their API Design
- Top 5 Most Popular Themes On API Evangelist In 2014
- Query Parameter Determining Which Fields Are Queried For API Call
- Now Our Development Environment Is Now Containerized And Scalable Like Our Production Environment
- Guest Post: Let Our Sponsors Blow A Little Smoke Up Your Ass
- API Discovery Continues Its Move Into The IDE With Eclipse Che
- Evolving Beyond Just Resources Towards A More Experience Based API Design
- Another View of The API vs. Data Download Model
- If You Have A Publicly Available Mobile App You Have a Public API