BT

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

| 作者: Jean-Jacques Dubray フォローする 3 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2011年8月21日. 推定読書時間: 2 分 |

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

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

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

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

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

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

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

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

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

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

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

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには 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