アーキテクチャに関する幻想

作者 Boris Lublinsky , 翻訳者 編集部Ｎ 投稿日 2011年10月2日

セクション

設計/アーキテクチャ,

デベロップメント

トピック

JavaScript ,

動的言語 ,

REST ,

言語 ,

プログラミング ,

Architecture ,

エンタープライズアーキテクチャ ,

設計

共有 |

原文(投稿日：2011/09/28)へのリンク

William Vambenepe氏は彼の新しい投稿、AJAX+REST、最近のアーキテクチャ上の幻想 によって、webに革命をもたらすはずだった15年前の構想を思い出させた。

その構想では、webサーバーは全てデータを持つXMLファイルを返す。XMLと一緒にXSLT（これはどのようにXMLをHTMLに変換するかを記述している）も。ブラウザはXMLデータにそれを走らせて、生成されたHTMLを表示する。出来上がり！これはHTMLモデルを吐き出す古いサーバにあらゆる恩恵をもたらすはずだった。XMLは簡単に他のアプリケーション（人間ばかりでなく）よって利用でき、様々なXSLTは色々なクライアントプラットフォームに適応するのに使うことができる、ということだった。

時間は過ぎ、この考えは決して実現されなかった。今ではAjaxにどんどん進んでいる。

XMLドキュメントは存在するが、普通JSONと呼んだほうがいいだろう。XSLTは今や膨大なJavaScriptになった。このモデルのほうがXSLTモデルより多くの利点がある。遥かに柔軟性があり、小さなアップデートができ、ページを部分的にリフレッシュできるなど。しかし、それはまた、データAPIをレンダリングロジックから分離するように、アーキテクチャ上の美しさを維持するだろうか？

Vambenepe氏は、見た目のエレガントさとアーキテクチャに良いことばかりなのに、なぜこのモデルがほとんどの状況で役にたたないのかを説明している。

同じサービスのクライアントが異なったインタラクションモデルをサポートし、1つのAPIで手が負えないほどバラバラにならずに、全てと上手く動くようにするのは難しいのです（「1つのAPI」と呼べるようなものでなくなる）。しかしもしAPIの表面を小さく保ちたいなら、何でもしゃべるおしゃべりなアプリケーションになってしまうでしょう。

しかし、氏の意見では、これはこのアプローチの多くの問題の単なる1つにすぎない。彼が指摘する別の大きな問題は、以下のような事実である。そのようなアプローチは、

... ブラウザコードとサーバーコードを統合するフレームワークには向きません。全てのweb開発者がクライアントフレームワークとサーバーフレームワークを2つのツールと考えたい、とは必ずしも思っていません。それらを1つの、予めまとめられたツールは最適なコードを提供しないかもしれませんが、それでも開発リソースの最適利用にはなるでしょう。

氏の強力な論拠にもかかわらず、彼の投稿には疑問がある。何が正しい方法なのか？あるUIの GWT スタイルに別々の REST APIを作成／生成する。そのようなアプローチはUIの実装を単純にする。ところが各UIに新しいAPIが必要になる。このアプローチはもっとスケーラブルか？もっとコストがかかるのは何か？UI統合あるいはバックエンドAPIの実装か？この投稿からもう1つの重要な問題が出てきた。正しい設計アプローチは何か？バックエンドAPIを実装して、次にそれを使って複数のUIを設計するか、UI設計から始めて、次にサポートするAPIを定義するのか。伝統的には、APIの実装の方がもっと高くつくが、APIそのものはUIと比べたらずっと安定している。

そうです。あらゆる目的に適う1つのAPIは、アーキテクチャ上の幻想である。しかし、良く設計された、再利用可能なAPIの小さなセットは多くのUI (Ajax) 実装の基盤として使うことができる。