13. Hypermedia controls, i.e. <a>, <link>, <form>
Rich semantics, i.e. <ul>, <ol>, <dl>
Enhance using micro format style
Already standardized
Everybody knows it
Good tooling support
For native apps: embed in a ”web view”
14. Q: Only GET/POST?
A: No problem for Fielding.
Q: What about size?
A: Gzip is your friend.
Q: What about parsing?
A: Use existing libraries for your platform.
43. Why supporting so many different type of platforms/browsers?
Data sent with <form> POSTs is flat – conventions needed?
How about mapping between <form> fields and native forms?
How to integrate ”web views” in a good way?
What about offline support for these views?
How does this relate to testing?
How does this relate to design?
How does this relate to ideas in Lean Startup?
Editor's Notes
The zombie apocalypse has begun.The number of different types of connected devices is increasing. We have already built ourselves a large amount of code duplication between client applications (both native apps and web apps) and it's only getting worse. Also, cheap low-profile devices are getting bigger market shares and users will still expect a good experience when using our software.To solve the problem of code duplication on the clients, we need to pull as much code as we can from the clients back to the server. A good way to achieve this is to build a Hypermedia API and to use HTML as the media type for the API. A nice side-effect of this is that we can show the received HTML directly to the user, which will be good enough for a majority part of a client application.The problem of low-profile devices is best solved by using Progressive Enhancement, which will allow us developers to provide the best experience that the device is capable of delivering.Finally, combining HTML Hypermedia APIs and Progressive Enhancement will allow us to have a single endpoint for our web and our API.Grab your keyboards and join the resistance!
I believe I have a story to tell... What is it about? It’s about the present and the future.
The number of native platforms is growing. Not only mobile, but also tablets, smart TVs, etc..
Oneproblem is that many apps contain a lot of knowledge about the business – something that they should know nothing about. Examples include validation rules, meta-data for forms, authorization rules and allowed views and actions on entities for particular states of the entity and/or the user. This knowledge often comes in the form of a requirements specification or other documentation. One consequence is that business knowledge will be duplicated on all developed clients, which is both ineffective and error-prone. It would be much better if an architecture was used that allowed for dynamic client behavior based on server-sent meta-data.
The current way of developing native apps doesn’t scale. We can’t continue to develop 100% native apps without some kind of reuse between the mobile platforms, but on the other hand, 100% code reuse often makes the end-user experience slightly boring. We want something in between – we want to make the most important use-cases really shine and differentiate on those, while less important use-cases get a less costly treatment. That is, we want to invest our effort in the areas of the app where it matters the most; think leverage.On the other hand, 100% native is thought to be risk free for a developer to suggest. But perhaps it’s not risk free for the business itself.
For Single-Page Applications on the web, the problems are similar. First, we want to focus the investment only on the most important use-cases, using less costly options for the rest of the use-cases. Business logic in the client-side will also, most likely, be duplicated between native apps.
Today, “apps” is no longer a concept only for mobile devices. Today, apps are being developed for desktop platforms (i.e. Windows 8) and smart TVs (i.e. Samsung, Sony). We don’t know what platforms will exist within a few years from now, but we can expect that there will be many of them. What is your strategy for handling the growing number of platforms?One solution to this problem is to build an API that follows the REST principles – a RESTful API, or, if you like, a Hypermedia API.
If we want to start to use hypermedia in our API, we have an important design decision to make: what media type(s) should we use? A good place to start is to look at already existing media types, to see if one could fit our scenarios.
Mike Amundsen has created a good summary of existing media types, using what he calls hypermedia factors.http://amundsen.com/hypermedia/hfactor/
We see that HTML has a lot of these factors built in. And, as we know, there are lots of existing clients (browsers) that already understand HTML, compared to the JSON based media types.JSON is not a hypermedia type – instead we can use HAL, collection+json and/or Siren.http://amundsen.com/hypermedia/hfactor/Examples for factors missing from HTML:CR, ”Support for modifying control data for read requests”, e.g. HTTP Accept-* headersLI, ”Support for idempotent updates” (HTTP PUT, DELETE)
Jon Moore has written an excellent article [http://codeartisan.blogspot.de/2012/07/using-html-as-media-type-for-your-api.html], where he describes the benefits of using HTML as the media type for an API. I can really recommend reading that article – it's excellent. In summary:-HTML natively support rich semantics and can be enhanced using the micro format style [http://microformats.org/about]- It offers hypermedia controls, such as <a>, <link> and <form>- HTML is already standardized and has been in use for decades- Almost everybody already knows HTML (reading, at least)- The tooling support for HTML is good – both on the client and server sideEven if you don't want your API to be consumed by a browser, there are still lots of benefits by using HTML as your media type. But a very nice side-effect of choosing HTML is that it can be consumed by a browser.
- It’s ok to only use GET and POST in order to be a RESTful API [http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post]-Information expressed in HTML is not larger than if it was expressed in JSON, if you gzip it
It's beyond the scope of this presentation to describe how to design the HTML for your API. In summary, very briefly, use as much semantic markup from HTML5 as possible and use the micro format style for your domain specific information. I recommend reading the chapter “HTML Hypermedia” from Mike Amundsen’s excellent book “Building Hypermedia APIs with HTML5 and Node” for more information.Also, Steve Klabnik’s e-book/wiki/blog “Designing Hypermedia APIs” i.s a good read
Capability fragmentationWhen technology evolves, there is competition around all market segments. For the high-end market segment, we get a race-to-the-top, where suppliers try to outperform each other on quality for a relatively fixed price. For the low-end market segment, the opposite occurs – we get a race-to-the-bottom, where suppliers try to outperform each other on price for a relatively fixed quality. Finally, these two feedback loops make space for one or more middle-segment markets.
It seems like that the majority of consumers wants a good-enough device for a reasonably low price, if available. This means that most people will have a device that is in the low-to-middle markets.With this in mind, consider what the future looks like for the mobile device market. Also consider that each device will be equipped with a web browser.
In 2011, the cloud platform company NetBiscuits collected data about the different types of mobile devices that accessed their services [http://www.netbiscuits.com/mobile-metrics-report-2011] – in total 8.5 million unique visits. In turned out that 40% of their mobile visitors came from three different types of iOS devices. The rest (60%) of their mobile visitors came from 3112 other types of devices, each having up to 3% of the total number of visits – the long tail. We can assume that these devices differ a lot in terms of screen size, performance and features – in short, capability fragmentation.3 iOS devices – 40%3112 other devices – 60%, up to 3% each
How should we as developers deal with capability fragmentation? For native app developers, the biggest problem nowadays seems to be to support different screen sizes, but I also think that allowing for different performance and features (within the same native platform) will matter more in the near future.
For web developers, the problem is much worse.
It seems that it’s no longer a sufficient solution to split up a web site in a “desktop web” and a “mobile web” – following this pattern of separation, we need to build a “tablet web”, an “e-reader web” and soon a “smart TV web”. And each device group will be fragmented internally, so separation does not help us much.
And who knows what kind of ”devices” will have browsers in the (possible near) future?
We do not need more separation. Instead, we need unity.
Progressive Enhancement and Graceful Degradation are two different cross-browser strategies. I like to think of Progressive Enhancement as a bottom-up strategy and Graceful Degradation as a top-down strategy: with Progressive Enhancement, you begin with a solution that delivers the most basic experience to as many browsers as possible and then you enhance the page for browsers with more capabilities.
With Graceful Degradation, you do the opposite and begin with a solution that only works in modern browsers and then provide fallbacks and/or error messages for the other, less capable, browsers.
But problems arise for Graceful Degradation when “new” does not imply “modern”, or, more correctly, when “new” does not mean more capable. Further, fallback solutions makes the system increasingly heavy and complex. And as the buyer of a new device I would prefer not to get error messages of the type “feature not supported”. Instead, we should consider using Progressive Enhancement and “mobile first”.
We begin with designing and developing the solution targeting basic mobile web browsers, sending only the most basic HTML, together with a reference to a small CSS file, and then progressively enhance the solution for browsers with more capabilities. It is out of scope for this presentation to list all the available principles and techniques for this type of solution (and there is currently an ongoing discussion among web strategists and web developers on this topic), but here are a few principles and techniques:- Develop your solution mobile first- Think content first [http://www.lukew.com/ff/entry.asp?1390]- Think use-cases (or stories) first
- Use ResponsiveWeb Design. Media queries is not the only solution, you can also use fluid layouts.
- Use delayed and conditionally loaded content [http://24ways.org/2010/speed-up-your-site-with-delayed-content, http://24ways.org/2011/conditional-loading-for-responsive-designs]- You can bundle several AJAX requests into one [http://filamentgroup.com/lab/ajax_includes_modular_content/], but in that case you need to think carefully about how caching should work
Also, remember that laptops can be connected to 2G/3G connections and that mobile devices can be accessing internet through a good WLAN.
- It’s seems to be possible to get a clue on the connection speed using the HTML5 Navigation Timing API, but this needs to be explored further.
I highly recommend watching the presentation “Progressive Enhancement 2.0” [http://www.webmonkey.com/2012/03/video-progressive-enhancement-2-0/]. The book “Adaptive Web Design - Crafting Rich Experiences with Progressive Enhancement” [http://easy-readers.net/books/adaptive-web-design/] is also a good read. Finally, the Resource-Oriented Client Architecture style [http://roca-style.org/] contains many good requirements and suggestions.
The API and the web can be the same thing!This is the most important part of the presentation: if we choose to use HTML as the media type for our API and use the “Mobile First with Progressive Enhancement” strategy….
... we see that we have two endpoints in our solution that would produce similar responses – perhaps not exactly the same responses, but very similar. The main difference would be that the web endpoint would include references to JavaScript and CSS files, but in a well-crafted solution these references would only consist of a few lines of code.
... we see that we have two endpoints in our solution that would produce similar responses – perhaps not exactly the same responses, but very similar. The main difference would be that the web endpoint would include references to JavaScript and CSS files, but in a well-crafted solution these references would only consist of a few lines of code.
It seems to makes sense to start with only one endpoint and see if we actually need separate endpoints for the API and the web. If the need for separation is high enough, we can split the solution at a proper level, but then we need separate URIs for the web and the API. To eliminate this problem we should make a separation on the URI level, which can easily be done by duplicating DNS entries.The seems to be a small mismatch between how web sites HTTP requests/responses are designed and how APIs are designed. But from these discussions I have witnessed online, these mismatches resolves. Look at the HTTP spec.You can include a menu for the web server-side, since you separate on URIs. Because, in the API, you only want a link to the menu/root, not the menu itself.
For existing solutions, the situation is often more complicated and complex. Though, a good strategy seems to be to develop an alternative design in parallel with the existing one and then increase the usage of the alternative design gradually.
Those involved with financing, designing, building, testing and deploying the solution should not loose focus from the whole!The need for vision and architecture is even more important when we start building for multiple clients.
Summary
One driver for building an HTML Hypermedia API is the continuing fragmentation of device platforms. HTML Hypermedia APIs will allow us to develop client apps (web and native) in a more effective way, both by reducing duplicated business logic in the clients but also to allow for the option to render the received HTML as it is.In a near future, the majority of devices will belong in the low-to-middle segments of the market. The continuing fragmentation of device capability is the main driver for a progressively enhanced mobile first solution.An ideal architecture for some systems could be to let the API and the web be the same thing (except on the URI level). It could at least be a good starting point.
Questions?
Questions?
Did you notice that I did not mention anything about zombies during this talk?To find out how this talk relates to zombies – use your imagination and your creative mind.Thankyou!----Image resources---Containerhttp://www.sxc.hu/browse.phtml?f=download&id=314638Hammerhttp://www.sxc.hu/browse.phtml?f=download&id=222086Juggling monkeyhttp://media.smashingmagazine.com/wp-content/uploads/2012/07/juggling-monkey.jpgUnityhttp://www.unitylakeorion.org/wp-content/uploads/unity.jpgKindlehttp://www.blogcdn.com/www.engadget.com/media/2011/09/amazon-official-kindle-touch.jpgiPad in sofahttp://www.itouch-magazine.eu/wp-content/uploads/2010/05/iPad-Lapdesk-Render-3-1024x797.jpglaptop on trainhttp://medmondtech.files.wordpress.com/2011/06/080910090104-laptop-train-travel-man.jpgRazorhttp://4.bp.blogspot.com/-UJsfWWvWgbk/Tb2RS3iFDoI/AAAAAAAAD0k/4XCA3sgsP3A/s1600/Occams-Razor_1896-l.jpgStalkerhttp://cdn3.openculture.com/wp-content/uploads/2010/07/tarkovsky.jpgDollarshttp://wallpaperstock.net/100-dollar-bills_wallpapers_10251_1920x1440_1.html
For Single-Page Applications on the web, the problems are similar. First, we want to focus the investment only on the most important use-cases, using less costly options for the rest of the use-cases. Business logic in the client-side will also, most likely, be duplicated between native apps. The deployment problem for native apps is however less of an issue for Single-Page Applications, since the client code is not deployed.
- Client techniques and server techniques complement each other
