ソフトウェア開発者のEvan Cordell氏は数週間前のAPI-Craftメールリストで，ハイパーメディアのREST制約は一般的なWeb API要件とどのように違うのか，という議論の口火を切った。
"REST主義者的危機(RESTistential crisis)"と題した論議の中で氏は，長年の議論と実践によってRESTスタイル最大の秘密，ハイパーメディア制約が明確になり始めたことを指摘している。Webでも明らかなように，人間中心のインタラクションには完璧に対応しているが，その一方でプログラマブルなWeb API一般においては，有用性に対する懸念がWeb APIコミュニティの中で増しつつあるようなのだ。
RESTに関する説明，ドメイン特有のWeb APIに適用した場合のハイパーメディアの制限，といった話題から始まった今回の議論では，新たなアーキテクチャスタイルの必要性の検討や，RESTを最大限に活用しながら効率性と信頼性の高いマシン・ツー・マシンのコミュニケーションなどのメリットを享受するためのインターフェース修正などが話し合われている。
議論で引き合いに出された関心事のひとつとして，長期間にわたってインターフェースの変更に対処するためのさまざまな方法に関するものがあった。最初のソリューションは，複数のAPIバージョンを並行運用すると同時に，さらにNetflixの事例のように，特別なユーザエクスペリエンス専用のオーケストレーションAPIを用意するというもので，自由度が高い反面，設計や運用などの面では難しい課題もある。
第２のソリューションは，変更に対処可能なRESTfulハイパーメディアAPIを事前に設計してユーザへの影響を限定的にするという，さらに労力を必要とするものだ。HTMLブラウザやサーバがこれまで開発や革新を行ってきた方法に近い。しかしながら，WebエンジニアのMike Kelly氏に代表される一部の関係者からは，導入に伴う複雑さや，API利用者への負担の増大を懸念する声もある。
以下の一覧は議論を要約したものだが，各章の題名などにはCordell氏自身の最初のメッセージからの抜粋を使用する。
1) よいAPIは変更されない
- 公開Java API設計におけるJoshua Bloch氏の経験から，プログラマブルWeb APIと同じルールが適用可能と思われる。
- APIはFacadeパターンに従ったインターフェースであり，クライアントに公開するサーフェースなどの変更は望ましくない。ただしランタイムデータを含む実装の多様化や展開については，APIの制約そのものを変更しなくても公開可能だ。
2）バージョン管理は機能しない
"Web API"は"従来型"APIに比較よりもはるかに多くのものを公開する。Web APIが公開するのはデータだ。しかも多くの場合，定常的に変化する大規模なデータセットを対象に，その現在の状態を公開する。例えばドメインモデルに，データを部分的に共有しているがアクセス方法が違う２つのバージョンがある場合，効果的にバージョン管理できるのか？ ユーザに互換性を失わせることになるはずだ。
- ハイパーメディアは，APIの脆弱性の低減や進化を支援することが可能だが，データやドメインモデルは根本的に変化する場合がある。クライアント側はこのような変更すべてに自動的に対処することはできない。開発者による人的介入が必要だ。
3) ハイパーメディアはリソースロケーションを崩す
- RESTはURIの固定化やサーバリソースに関するユーザの先入知識を防止するが，実際にはユーザはURIを記録(ブックマークなど)している場合があり，サーバにはURI空間の改良を行う必要がある(リダイレクション)。
- ハイパーメディアは，適切なハイパーメディアフローに従わないユーザの怠慢からAPIプロバイダを隔離してくれる訳ではない。特定のリソースやURIに直接振り向けるのである。
- ハイパーメディアAPIは非常に複雑で，理解や利用が難しい傾向がある。そのため開発者はやむを得ず，API更新からクライアントを分離する機構をすべて迂回して，クライアントを最適化する作業を行っているのが実情だ。
4) ハイパーメディアはマシンではなく，人間であるユーザのためのものだ
- 時間的経過に伴う変化に対してマシンはうまく対応できないが，人は変化をよく解釈して，次に何をしたいのかを決定できる。ハイパーメディアはマシンよりも，人間に対して非常に自然な存在だ。
- ドメインモデルで生じた変化は，クライアントに処理方法の変化を要求する。その部分では，ハイパーメディアは何の役割も果たさない。
真のREST/ハイパーメディアクライアントは，実際にはAPI (AHI - Application Human Interfaceと言ってもよい)よりもHCIの形を取る。
5) アウト・オブ・バンドの何が問題なのか？
- そもそもAPIは，本当に探索可能である必要があるのだろうか？
- APIの応答フォーマットは複雑性が非常に高レベルで読解困難でありながら，なぜAPIが自己文書的である必要があるのか？
- ブラウザによってレンダリングされる対話的なサンプルと明確な説明があれば，適切に構造化されたHTMLの方が可読性は高い。
6) ハイパーメディアAPIとWADLにどれほどの差があるのか？
探索可能なハイパーメディアAPIに，それほどの独自性があるのだろうか？"HAPI"とは，広範に分散されたWADLを備えたAPIのようなものだ。単一のエンドポイントから始まり，その応答に基づいてAPIで何が可能なのかを把握する，という手順に変わりはない。
- ドメインモデルには，何らかの形で説明をする必要がある。さらにそれは，経時的に変更されなければならない。
7) Web類似体
- ネイティブなモバイルアプリでのRESTには，Android MLとiOSML言語によるコードが求められる場合がある。
- ドメイン固有のハイパーメディアのメディアタイプを使用するには，このドメインを理解する特別なクライアントコードを書くことが依然として必要だ。
8) RESTの真のメリットは何か
- ハイパーメディアやドキュメントのWebと比較して，RESTには次のようなメリットがある。
- サーバにステートレス化を強制して，スケールを非常に容易にする。
- 情報とリソースの分離を促進する。
基本的には，文法的に意味のある方法でサーバと通信する，というシンプルなものだ。どのプラットフォームや言語にもあるhttpライブラリ以外には何も必要ない。
上記の要約には議論の参加者，特にEvan Cordel氏やMike Amundsen氏，Jorn Wildt氏，Mike Kelly氏の発言から抜粋したものも含まれている。免責事項として，筆者も当初，この議論に参加していたことを述べておく。
RESTとWeb APIという２つのアーキテクチャスタイルは，明確に区別すべきものだろうか。ユースケースとしての人間主導型ハイパーメディアと，マシン・ツー・マシン・コミュニケーションについてもそうだろうか。読者自身の経験に基づいた考えを教えてほしい。