"Building Hypermedia APIs with HTML5 and Node"と"RESTful Web APIs"の著者であるMike Amundsen氏は先頃，かねてから開発を続けていた新しいメディアタイプ設計を発表した。"Uniform Basis for Exchanging"を略してUBERハイパーメディアと呼ばれるこのメディアタイプを，氏は次のように説明する。
Uberメッセージフォーマットは最小限のリード／ライトを行うハイパーメディアタイプです。シンプルな状態転送と，アドホックなハイパーメディアベースの状態遷移をサポートするように設計されています。本資料ではXMLとJSONという２バージョンのフォーマットについて説明するとともに，UberメッセージをHTTPプロトコル上でサポートするためのガイドラインを提供します。
HAL, JSON, API, Hydraなどといった，ハイパーメディアフォーマットのカンブリア爆発があったのはつい最近のことだ。これ以上必要なのだろうか？ 氏は次のように答える。
この分野で使いやすいメッセージフォーマットを設計するには，多くの経験を積む必要があると思います。この3年間で，過去10年間よりも多くのハイパーメディア設計がIANAに登録されたというのは，本当にすばらしいことです。多くの設計を見れば見るほど，優れたハイパーメディア設計の原則や実例を見出す機会も大きくなりますから。そしてUBERは，経験を積む機会をさらに提供するのです。
UBERに関して興味深い点のひとつは，プロトコル非依存であることだ。ほとんどのメディアタイプはHTTP上に構築されることを前提にしているが，UBERはさまざまなプロトコル上で動作する。氏はポストHTTPの世界の可能性を見ていて，UBERの活路はそこにある。
HTTPの登場から20年以上，アプリケーションレベルのプロトコルの中心的存在となってからでも15年以上になります。私たちが"Web"として知るものの大部分は，この唯一のプロトコルにそのほとんどを依存しています。HTTPの普及が確定的でなかった頃を思いだすのは困難ですし，HTTPがいつかは世界中でもっとも普及したデータ転送手段としての役割を終えるかも知れない，と想像するのはさらに難しいことです。ですが私は，HTTPがいつの日か，10年後，20年後，あるいはそれ以上先になるかも知れませんが，他のアプリレベルのプロトコルに取って代わられることを前提にしています。ですから私は，それを考慮に入れた設計を今から経験しておきたいのです。
メディアデザインの分野で，いまだ探索中の領域のひとつがエラーメッセージだ。汎用的なエラーメディアタイプを作ろうという試みはいくつもあるが，氏のデザインは，自身のエラーメッセージをインラインで含むというものだ。その選択について，氏は次のように詳説する。
UBERの設計で，エラー表現としてBen Longden氏のvnd.errorメディアタイプを使用しなかったのには，２つの理由があります。ひとつは，vnd.errorがIANA登録デザインではないということです。これは要件でも，よい設計の指標でもありませんが，登録されていないメッセージ設計への依存性をUBERに持たせたくはありませんでした。
もうひとつは，エラー情報は補助的ないし二次的な機能としてではなく，ハイパーメディアメッセージデザインのネイティブな部分として含めるべきだ，という考えからです。UBERメディアタイプのクライアントが動作する上で，他のメディアタイプのサポートを必要とするような要件を設けたくない，ということもあります。
ほとんどの人々がAPIに期待するものであるにも関わらず，UBERでは"オブジェクトの直列化はサポートしない"，と氏は宣言している。その理由について氏は，次のような長い文章で説明する。
私がこれまでに設計したハイパーメディアでは，いずれも直接的には，コードベースのオブジェクトからメッセージベースの状態表現への直列化をサポートしていません。理由のひとつは，任意のソースコードモデルと直行するメッセージモデルの設計を目標にしているからです。どのプログラム言語からも同じように利用可能にしたいのです。
ここ数年の間は，たったひとつの言語(JavaScript)が開発者の思考を支配してきました。そのために開発者たちは，JavaScriptのソースコードのような状態表現が必要だという前提に立っています。Webが普及した当初10年間はそうではありませんでした。HTMLやXMLはどちらもソースコードにとらわれない設計です。この見解は，いくつかの面で非常に価値のあるものだと思います。
また大規模な実装 – システムレベル – に関しては，オブジェクトではなく，状態を共有できるようなパターンが望ましいと思っています。この方法は，コンシューマ向けアプリケーションの開発とプロバイダ向けアプリケーションの開発が時間的，ないし空間的に分離されている場合，特に有効です。オブジェクトモデルよりもデータ要素について意見を合わせる方が，ずっと簡単ですから。 基本的に，直列化を基本とする設計では，オブジェクトモデルがアプリ構築上の”参入コスト”になります。アプリを開発可能にする以前に，オブジェクトモデルを受け入れる必要があるのです。 それにオブジェクトモデルは時間とともに変化します。単純なデータ要素よりも変更が頻繁です。事前知識の必要量の少ない – すなわちオブジェクトではなく，状態に基づいた – 設計は，2007年にStu Charlton氏が提唱した，Webにおいてセレンデピティ(偶然の発見をする能力)の原則を推進する方法のひとつです。
そして最後に，私が最近読んだ，ヒトやその他の動物が世界と対話する方法に関する読み物には，私たちが最初に知覚した生のデータは，獲得した情報を頭の中のモデルと比較することで初めて有用な情報になる，とありました。つまり2段階のプロセスなのです。最初は私たちの周りのものと対話するプロセスを模倣して，その次にデータをローカルモデルに変換するような，そういったアプリケーション開発に開発者を誘導するメッセージを設計したいと思っています。コミュニケーションをするためにオブジェクトモデルを共有する必要はありません。ただデータを共有すればよいのです。
ハイパーメディアのスペースが成長と変化を続ける限り，新たなメディアタイプが作り出されて，旧式のフォーマットを改善していくだろう。UBERのシンプルさ，注目点，HTTPの重要性の低減は，そのスペースへの革新的な入場門になる。