BT

Mike Amundsen氏のAPI設計ワークショップ

| 作者: Saul Caganoff フォローする 1 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2013年8月22日. 推定読書時間: 5 分 |

原文(投稿日:2013/08/19)へのリンク

Layer 7のプリンシパルAPIアーキテクトで,"Building Hypermedia APIs with HTML5 & Node"という著書を持つMike Amundsen氏は先頃,API設計に関する一連のワークショップのためにシカゴ,シドニー,メルボルン,トロントを巡る世界ツアーに出発した。InfoQは7月25日,メルボルンで行われたワークショップに参加した。

Amundsen氏の設計の秘訣はUSEパラダイムの重視にある。USEはUsable, Scalable, Evolvableの頭文字だ。ワークショップではこの方針に沿って,API実装に関する3つの共通"スタイル"について,USEの側面から見たそれぞれのメリットと制限を説明する。またバージョニングについて,長時間の説明の後に氏はこうアドバイスする "バージョニングは絶対に使用しないこと – どうしても必要な場合以外は。"バージョニングよりも拡張性(Evolvability)を活用すべきだ。

"ユーザビリティ(Usability)は製作物の使いやすさであり,学習のしやすさである" という定義を引用した上で,APIとは文字通り"インターフェース"であり,ユーザとタスクを重視したものであるべきだ,と氏は改めて指摘する。"実証的な計測を行って,インターフェース設計を繰り返すことが必要なのです。"

"スケーラビリティ(Scalability)とは,システムが処理容量の増大に適応できる能力である",スケールアップとスケールアウトの違いを理解してほしい,とAmundesnは言う。スケールアップは短期間で容易に実施可能だが,持続性がない。スケールアウトは短期間では難しい反面,長期的には信頼性に優れている。スケールアウトをサポートするには,DevOpsプラクティスを用いるとよいだろう。

"エボルバビリティ(Evolvability)"とは,システムの適応進化への対応能力である",氏は可能な限り,バージョニングではなくAPI拡張を行うように推奨している。"どうしても必要な場合以外,バージョニングをしないことです。そんな状況はほとんどないでしょう。" バージョニングは内部コード管理には合理的な方法だが,WebAPIユーザが気にするのは唯一,非互換性だ。"何も取り除かない"ようにすれば,非互換性を生じさせない変更が可能になる。インターフェースを拡張するということは,既存のデータ構造の意味は一切変更しない,追加部分はすべて省略可能とする,という意味だ。しかし時には変更を余儀なくされることもある。バージョニングを使用するのはその時だ。その場合には,バージョンを判別しやすくしておくこと。"ビルドやテストは簡単になりますが,ストリームを通じたデータ転送は難しくなります",と氏は言う。"しかしここでは,クライアントは変更を無視するものと考えておいてうださい。彼らはそうしたいはずですから。" 氏はバージョン識別子をURLに含めるようにアドバイスしている。クライアントが簡単に無視できるように,ヘッダやペイロードには置かないことだ。

続いてAmundsen氏は,API実装でもっとも一般的なスタイルとしてトンネル方式(SOAP),URI方式(CRUD),ハイパーメディア方式(REST)の3つを取り上げて,それぞれの歴史のレビューと長所,短所を交えて概説する。氏はこれらは"スタイル"であって標準ではない,という点を強調している。

トンネル方式では,トランスポートに依存しない方法でメッセージをリレーするためにSOAPを使用する。機能と手法に注目すれば,このスタイルは "ユーザビリティ" に優れていると言える。優れたサポートツールが存在している上に,企業用のガバナンス機構も強力だからだ。ただし"オール・オア・ナッシング"的ロックインに結び付くようなスタック依存性,不十分なHTTPサポート,プログラマ間での人気の低下,といった制限もある。エボルバビリティの面からは,SOAPには強力な管理機構と同時にバージョニングの問題がある。スキーマの些細な変更でさえ "非互換変更" になる可能性があるからだ。このような欠点を回避するために,多くの人たちがSOAPプロキシモデルを離れて,よりメッセージモデルとしてSOAPを使用するようになっている,と氏は指摘する。

URI方式は,HTTP動詞と(通常は)JSONデータ構造を使ってWebリソースを操作するという,おなじみの方法だ。Amundsen氏は,ハイパーテキスト駆動でないAPIはRESTではないと明言したRoy Fielding氏の2008年のブログ記事を引き合いに出して,この方式がRESTではない点への注意を促している。URI方式はオブジェクト/エンティティ指向のスタイルで,現在公開されているAPIの大多数が採用している。広く知られたHTTPを使用し,豊富なオブジェクトツーリングを持つこの方式のAPIは,"ハッキング”も比較的容易だ。ただしHTTPメソッドセットの少なさとURIモデリングが非標準である点から,ユーザビリティは損なわれている。ユーザはドメインメソッドをリソースとHTTPメソッドにマップしなければならない。Amundsen氏によればURI方式は "使い始めるのは非常に簡単だが, 拡大や改善には難しい" スタイルだ。

Amundsen氏が説明した最後のスタイルはハイパーメディア方式,あるいはRESTだ。ユーザビリティについては,Amundsen氏が"知識共有には不可欠"とするメディアタイプとリンクリレーションを加えることで,URI方式よりも拡張されている。ハイパーメディア方式は,タスクとユースケースを公開するという意味で,"SOAPがドキュメント作成ワークフローにおいて,マシン可読な方法で行っていたものに近付いている" と言える。ハイパーメディア方式はエボルバビリティの面では優れていて,長期間に渡って有用なサービスを実現可能なスタイルではあるが,難解とされている上に,利用可能なツーリングも多くない。Amundsen氏は注目すべきハイパーメディアとして,Sirenを挙げている。

Amundsen氏は,InfoQにこれまで何度も貢献している。Leonard Richardson,Sam Ruby両氏との共著となる新作 "RESTful Web APIs" が9月に発売される予定だ。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT