unRESTは新しいRESTか

作者 Mark Little , 翻訳者 徳武 聡 投稿日 2011年7月14日

セクション

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

設計/アーキテクチャ

トピック

SOA ,

REST ,

Architecture ,

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

サービス契約

共有 |

原文(投稿日：2011/07/10)へのリンク

RESTについて少しでも触れれば人々はふたつの陣営にわかれてしまうと言っていいだろう。しばらくの間、RESTはWS-*の波と戦っていたがこの障害を克服したら、RESTには利益はあるものの、その利益は他の人が考えているよりもすくないのではないかと思っている人々の間で議論がわき起こった。"REST主義者"が信じていること全体に反対の立場を示しているのがJean-Jacques Dubray氏だ。氏は最近unRESTと題した記事を書いた。氏によれば、

2007年以来、一握りの人々は業界に向けて、"ウェブ"が分散コンピューティングのすべてを教えてくれる、私たちが今までやってきたことは単なる間違いだったのだ、と諭していました。4年経って、分かったのはその王様たちが裸だったということです。

氏の議論の核心は、RESTはブラウザを念頭において設計されているため、ブラウザでの利用の外では本質的にはunRESTfulに成らざるを得ないということだ。

RESTはエンドユーザを念頭において設計されています。ユーザエージェント、つまりブラウザが念頭に置かれています[...]。ソフトウエアエージェントとサーバとの通信にRESTを適用しようとして作られたものはすべて間違っているということです。[...] このような思いがけないような複雑さに注力するのはそろそろ止めるべきです。このやり方は、以前の分散コンピューティングのパラダイムでは自由にできたコーディングを取り上げることで生産性を削ぐこと以外に何も生み出しません。

氏の言葉で言えば、RESTは"問題に手軽に適用しにくく"、"RESTlessにした方がかっこいい"。これはどいうことか。氏は従うべきいくつかのルールを示している。

• ドメインに特化した統一インターフェイスを定義する: "恥ずかしがらないでください。HTTPの4つしかない動詞は忘れてください。あなたは独自の動詞を定義できるのです。例えば、Query/Do/Notify/Synchronizeは最適でしょう。これは、このウェブAPIのすべてのメソッドは問い合わせかアクションか、通知か同期のいずれかに分類できることを示しています。"
• メッセージを明確に定義する: 通信するふたつのエンドポイントは交換するメッセージについて知らなければならない。しかし氏は、"きちんとしたAPI定義に必要なのはバージョン管理されていることがわかるはっきりとしたメッセージの定義です。メッセージがはっきりしていることが分散コンピューティングを動かします。"
• エンドポイントの契約をはっきり定義し、バージョン管理する: エンドポイントの間のインターフェイスとメッセージは規約の一部の交換形式だ。氏はマシンが理解できる規約から人間だけが理解できる規約にしようとする方法はうまくいかないと言う。氏の考えでは、このやり方によって、多くの時間が無駄に費やされた。"統一したインターフェイスは規約を形作るのに不十分です。これは規約の基盤にすぎません" 氏は、"ウェブAPI利用の健全なエコシステム"を構築する唯一の方法は、再利用や改善がうまくいくようバージョン管理された、マシンが理解できる規約だけだと考えている。

And that's it: with those 3 rules この3つのルールを守れば、しっかりとしたAPIの基礎が作れると氏は考えている。氏が言うには、氏の記事は単なる思いつきに基づいて書いたのではない。氏は最低でも過去10年間はウェブベースのプロトコルに関する仕事をしてきた。そのなかには、ebXMLも含まれている。あなたは、氏の考え方や下記のコメントに賛同できるだろうか。

これであなたは自由にunRESTできます。HTTPヘッダーに驚く人を静かに笑うこともできます。またはあなたの聞きたくないRESTの権威筋の話をしてくるかもしれません。しかし、RESTは(悪い)夢であり、unRESTこそがあなたのやりたいことなのです。

RESTについてもっと話したい人、特にクラウドのような領域にいる人にとっては、氏の言うことが正しくてももう手遅れだろうか。それとも、最初からunRESTfulな手法を取っているのだろうか。それともunRESTは"古き悪き日々"を思い起こさせるだろうか。