SOA，Webサービス，そして REST などの 標準に関する活動 については，何年にもわたって 数多く の 記事 が書かれ，プレゼンテーション が行われてきた。大方の意見では，特定ベンダへのロックインを回避し，異なった実装間の相互接続性を保証するものとして，標準の重要性を認めている。ところが最近になって Steve Jones 氏が，標準をSOAライフサイクルに適用した場合に起こり得る重大な問題を提起をした。氏によれば，開発者やビジネス上のステークホルダといった人たちが，必要とする標準の定義を初期段階で行っていないことに "衝撃" を受けた，というのだ。ただし技術標準に範囲を限るならば (WS-* のように)，彼らのこのような態度についても言い分はあるのだろう。氏の書いた記事はテクノロジ全般を対象としたものだが，その最初では REST を対象に次のように述べている。
"REST とはそういうものだ" と言ったり，すべてのものがダイナミックなのだから，と主張したりするのは，責任回避や怠慢にすぎません。
そして氏は，これが REST を使用する開発者にとって意味するものを説明する。
1. リソースへの仕様の公開方法，"GET" や "POST" が行う内容の説明方法について同意すること。
2. "サービス"/リソースの見本を作成し，利用者に必要なレベルのドキュメントを用意すること。
3. 最終型の完成を待たずにソリューションのテストや検証を行うための，モック／プロキシに関連するプロセスについて同意すること。
4. リソースに対するテスト実施のプロセス，その時点でのシステム要件への適合性の検証方法について同意すること。
その後には REST に関する要点が，氏の個人的な体験 ("私に対して昨年，リソースを正とみなすのが REST であるのと同様に，それがなすべき仕様はそれ自身の中にある，など，くだらない説明をする連中がいました ...") を引いて説明されている。その内容には，Bill Burke 氏が 2009 年に，REST-* への取り組みとして発表した時の提案 に近いものがある。
REST に関する説明の多くは Human Web を例にしています。ここで言う "Human Web" とは，ブラウザとその使用者のことです。私見になりますが，マシンベースのクライアントと REST アーキテクチャとの対話方法に関しては，まだごく初期段階にあると思っています。エンタープライズ IT において分散アプリケーションを実装する手段として，これまでは特定のミドルウェア技術セットが用いられてきました。REST の出現は，従来型のエンタープライズ IT 開発とミドルウェアとの接点のあり方を再検討する機会を，私たちに与えてくれているのです。
REST における合意されたアプローチ (標準？) の欠如は，長期にわたる検討と，氏が提起して 初期のエントリで議論したような反復アプローチを実施する原因になるのかも知れない。しかし同じエントリで指摘されているように，実装アプローチとして Web サービスを選択した場合には，ここ 10 年程で展開された標準を無視できる理由はほとんどない。WS-I 基本プロファイル 1.1 と SOAP 1.1 の２つは必須であるし，WSDL のバージョン選択 (1.1 または 2.0) は，サービスが実行するやり取りのパターンによって決められる。
WSDL 2.0 のコールバックが必要で，そこに技術的アドバンテージがあったとしても，WS-I 非準拠のプラットフォームを相手にしたときには，ごくお粗末な XML マーシャリングやヘッダクラッシュなどに見舞われるかも知れません。WSDL 2.0 をベースとした WS-I 準拠のローカルバージョンを自分自身で定義する，という選択肢もありますが，ほとんどの場合は優秀な設計とシンプルなアプローチを探す方が得策です。例えば，特定のプロセス要素に対して標準準拠のスキーマを持っていて，渡されたコールサービス名をレジストリ参照によって解析し，適切なコールバックサービスを選択する，というようなものです。
WS-* スタックには種々の標準が含まれているが，氏がコアと考えるのは WS-Security と WS-Reliable Messaging の２つだけだ (WS-Addressing も暗黙的に含まれているだろう。最近になって OASIS 標準で必要になったからだ)。ただし氏自身指摘しているように，このような標準の決定は最初のステップに過ぎない。標準が決定したとしても，実装を選択するためには，それがサポートする標準のバージョンを理解することが必要だ。標準準拠をうたう Web サービススタックの中には，実際には標準化前のリリース仕様をベースにしているものや，古い標準に準拠しているものがある。それらは，ユーザからは利用価値の低いものだ。最後に氏には，HTTP のパフォーマンスに不満な向きに対して言いたいことがあるようだ。
もうひとつは，トランスポート機構の標準としての HTTP に対する同意についてです。本当のところ，今年 2010 年は "パフォーマンス" に不平不満を言ったり，メッセージングの新たなソリューションを提案するのは止めにしたいものです。本当にパフォーマンスに問題があるなら試行錯誤するのもよいでしょう。しかし 99.999% は徒労に終わると思います，いっそのこと HTTP/S にしてしまった方がよいかも知れません。
Steve は最後に重要な指摘をしている。標準は望ましいものだが，それが単なるリップサービスであっては，SOA 開発者にもビジネス上のステークホルダにとっても利益にならない，という点だ。SOAライフサイクルの初期に正しい標準を選択することは重要な第一歩であり，それに気付かない大勢の SOA 実践者たちは，今現在も問題を抱え続けている。