RESTは明確に定義されたアーキテクチャスタイルであり，多くのメリットを持つ反面，あらゆる種類のWeb APIをそれで記述するような誤用例も少なくない - Jimmy Bogard氏は一連のブログ記事でこのように述べて，さまざまなハイパーメディアなどのメディアタイプ選択を始めとする，サーバからクライアントまでの完全なハイパーメディアソリューション実現の上で必要なものを強調している。
Microsoft MVPであるBogard氏は，"RESTとハイパーメディア"というRESTに関する固執のせいで，クライアントAPIとサーバAPIがともに著しく複雑なものになっていると指摘する。そういった努力が実を結ぶのは，クライアントとサーバが別々に開発されるような限定的なシナリオにおいてのみである，というのだ。クライアントとサーバが同じソース管理リポジトリ上にあって，同時にデプロイされるのであれば，ハイパーメディアのメリットはさほど大きくはない，というのが氏の意見だ。
メディアタイプを選ぶ上で，Bogard氏は３つの選択肢をあげる。
- 標準を採用する。
- 標準を拡張する。
- 独自に設計する。
氏自身は，可能な限り標準を使用している。ひとつのプロジェクトで実行可能な範囲を超えるような労力への投資はしないのだ。さまざまなメディアタイプの能力を比較する手段として，氏は，Mike Amundsen氏の提唱するH Factorを引用している。メディアタイプのハイパーメディアサポートレベルの計測値で，目の前にあるユースケースに対して最適なものを選択する上での目安となる値だ。しかしながら，選択したメディアタイプがすべてのニーズを満たしていないことも多く，その結果として氏は，不足部分の拡張を強いられることが少なくない。
プレーンなJSON API構築にリッチなハイパーメディアモデルの複雑さが加わった場合と比較するならば，サーバの設計や実装などはごく簡単な作業だ，とBogard氏は考えている。一般論として，選択されたメディアタイプを含んで実装されたAPIには，それがクライアントの観点から許容されるものであることをAPIユーザが検証する，という作業が必要だ。
クライアントの視点からBogard氏は，氏がこれまで見てきたRESTの実装例の大部分について，サーバ側のAPIは含まれているものの，同じAPIを利用するユーザ側の実例を示せていない，という問題点を指摘する。自らの例として氏は，基本的なナビゲート機能を画面に備えたWebクライアントを開発した。情報テーブルとペイロード内のリレーションやリンクを併用することで，ユーザが詳細部分にドリルダウンすることができる。サーバの送信するペイロードには多数のメタデータが含まれている。疎結合を維持するためには，クライアントに提供されるRESTが，このメタデータに基づいて動作する必要がある。そうではあっても，クライアントは目的に特化したものでなくてはならない，と氏は考える。一般性のある汎用クライアントほど退屈なものはないからだ。jQueryを使ってクライアントを構築すると同時に氏は，クライアントの設計と実装がReactに関連したものだと説明している。そのオブジェクト指向性がハイパーメディアには最適だという考えからだ。