REST クライアントを書くのは難しい？

作者 Jean-Jacques Dubray , 翻訳者 吉田 英人 投稿日 2011年8月21日

セクション

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

設計/アーキテクチャ

トピック

HTTP ,

REST ,

W3C ,

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

Architecture ,

仕様

共有 |

原文(投稿日：2011/08/16)へのリンク

Programmable Web の Adam DuVander 氏が先週，API エクスペリエンスに関する調査 の報告を行った。そこからは，開発者が Web API を使用する時に直面する，大きな問題がいくつも 浮かび上がってきている。その中には最も人気のある API も含まれている。

API を利用する上で体験する悩みや不安などの問題についての質問に対して，長文形式の回答で他の何よりも多く言及されていたのは Facebook API でした。Google API や Twitter API について書いたものもかなりありました。この３つの API が開発者の間で最もよく知られた存在である，という理由もあると思われますが，Hacker News 読者を対象とした今回の調査結果からは，学ぶべき教訓があります。

API 統合とメンテナンスに関するコスト評価を目的として 調査 を行った Trove は，その結果をブログで次のように報告している。

[API プロバイダが] 開発者に提供しているサービスは不十分です。ドキュメントは粗悪ですし，OAuth などのサービスは問題含みです。API は予告もなく不規則に変更される上，業界標準のようなものも，回避策を見出せるようなベストプラクティスもありません。これら API 上で生計を立てる開発者として，私たちにはもっとよいものを求める権利があります。

API 統合に関する最大の悩み：そうですね，私たちには驚くことでもないですが，主な不満点のリストをあげてみました。

• 粗末なドキュメント (どの程度でしょうか)
• OAuth (おや，OAuth がお嫌いですか)
• 粗悪なエラー処理
• サンプルコードの欠如
• テスト環境の欠如
• 言語間で共通なライブラリの欠如
• 変更と非互換の繰り返し (皆さんと一緒に，ここでは Facebook と声を大にしたいところです)
• 内部構造に一致するように正規化されたデータ
• 利用と乱用の境界
• 一方的な使用量制限 (サービスによって異なります)
• 標準の不一致 (REST 対 SOAP 対 XML-RPC，XML 対 JSON 対 POST，バージョニング対非バージョニング，など)
• ファイアウォールを越えて開発機に接続する場合のサービス取得

一体どれを選べば楽になるのでしょうか: 一般的に言えば ... どれもだめです！ ただし Mashery と Apigee には特別賞を与えてもよいでしょう。

このような状況下において Trove はしかし，開発者が時間とともにメンテナンスの改善を感じている，という意外な発見をした。

私たちの最大の前提のひとつは，統合サービスに関するメンテナンスのオーバーヘッドが年を重ねる毎に悪化していく，というものでした ... しかし調査の結果は，それとは逆だったのです。

この結果の解釈について，彼らは依然として慎重であり，その意味をより理解するための別調査の実施を予定している。