Zapier、APIのダウンを発見する監視サービスを公開

Zapierはオンラインサービスを繋ぐ作業を自動化するサービスだ。このほど、200種類のAPIを監視するサービスを開始した。時にはプロバイダーより早くダウンを見つけることもある。

新ツールは、Zapierでサポートしている全APIのアップタイムとダウンタイムを監視する。人気のウェブAPIのリアルタイムの状況やZapierのサービスを利用している顧客への影響をモニターする他、単にAPIの動きを追跡するための便利なツールとしても使える。各APIは、SMS、 インスタントメッセージ、メール、その他Zapierの中核サービスでサポートされている様々な方法を使って監視できる。

Zapierの共同ファウンダー、Wade Fosterは監視サービスを開発した理由について、ベンダーは主要製品については性能監視用のダッシュボードを提供していることが多いが、APIにはなかったからだと言った。これは AmazonDesk.com37Signalsなどのサービスについて言えることだ。APIがアプリ同志を繋ぐ糊となっている今、これは問題だ。その結果APIがダウンすると消費者は闇に置き去りにされる、とFosterが最近のメールで語った。例えば、Google APIがダウンした時、Zapierはほぼ瞬時に発見した。

そのダウンに関するHacker Newsのスレッドがこれだ。「相棒の共同ファウンダーは、そこでトップコメンターになっている。それに続くコメントの数々が、われわれがこの機能を公開する後押しになった」とFosterは言った。

ダッシュボードは公開されてから約1週間になる。ほぼ全ては常時稼動中であり、最近のアプリケーションの質の高さをものがたっている。

これはかなり嬉しいサービスだ。アプリに組み込んだ複数のAPIを監視しなければならないデベロッパーにとっては特に重要だ。

[原文へ]

(翻訳:Nob Takahashi)


今、起こりつつあるAPIエコノミーとか何か?

何という2週間だったろうか。しばらくの間くすぶって何かが起こった。API市場が爆発したのだ。IntelはMasheryを1.8億ドル以上で買収し、CAはLayer 7を買収した。3ScaleJavelin Venturesから450万ドルの資金を新たに調達した。MulesoftはProgrammable Webを買収した。そしてついにFacebookもこれに加わりParseを買った。

これらの買収や出資は、アプリケーション界に広がるAPIの遍在によって、ある市場が成熟しつつあることを暗示している。それは決して新しい市場ではない。この分野は過去数年間に構築されたAPIをてこにしてきた企業に埋めつくされている。むしろこれは、変曲点というべきだ。主要APIディレクトリーのProgrammable Webによると、現在APIは3万種以上ある。Javelin Venturesのマネージング・ディレクター、Noah Doyleは私のインタビューに答えて、アナリストらはAPI市場が今後5年間で5~10倍に伸びると予測していると語った。

こうしたAPIの規模拡大によって、魅力あるアプリとAPIを作るデベロッパーにとって好循環が生まれる。APIは分散データネットワークの一部となることによってアプリのリーチを広げる。そのAPIを使う人が多くなるほど、アプリ開発者はより多くのデータを生み出す。データの利用範囲が広がればそのサービスはAPIになる可能性が高まる。

Facebookは、新たなデジタル製品を送り出し続けるために新しいデータの流れを必要としている。Parseのような〈サービスとしてのバックエンド〉プロバイダーは、デベロッパーが基本データタイプや位置情報、写真などを保存するインフラストラクチャーにアクセスするSDKとAPIを提供する。どうやってFacebookがこのデータを利用するかは未だに疑問だ。しかしそれでも、ParseはParseプラットフォーム上でAPIを使用するアプリに育まれた活気ある安定データ源としての役目を果たす。今後このデータをどのようにパッケージ化、セグメント化し、その10億ユーザに対して効果的な広告を送り出すかを決めるのはFacebookだ。

APIは接着剤のようなもの

APIはインターネットの接着剤になる、とProgrammable Webのファウンダー、John Musserは言う。Musserは、Doyleと同じくこれを、モバイル端末の需要から生まれ様々な面で新しいクライアント・サーバーの役割を演じる新しい世代のAPIとして期待している。それらのアプリは、クラウドサービスでホスティングされ、モバイル端末に配信されデータを読み書きし、情報を送受し、API経由で互いにつながりあう。

第一世代では、MasheryやApigeeなどの会社がAPI管理分野の先陣を切った。Twitterをはじめとするウェブ企業が第2世代を形成した。第3の波では、IntelやCAといったエンタープライズ企業がこの大きな動きを察知し、ハードウェアとソフトウェアシステムをつなぐべく市場に参入した。

今やAPIの動きはアプリケーションや機械レベルの下方に向かっているとDoyleは言う。それは〈物体のインターネット〉が出現するレベルにまで来ている。あらゆるものがプログラム可能になり、データの送受信、統合、そして動作のトリガーが可能になる。

3Scaleが提供するAPI管理システムでは、デベロッパーがその上にロジックを作ることできるとDoyleは言う。これを使うとデベロッパーは、あれこれ手を加えることなく、APIにそのままデータセットやサービスを追加できる。

APIエコノミー

この動きの高まりは、Apigeeの戦略担当副社長、Sam Ramjiが提唱に一役買った用語、〈APIエコノミー〉を象徴している。Ramjiは、APIとAPIインフラに注目する人々の数はこの一週間で2倍になったかもしれないとメールに書いた。「APIを持っていない会社のCIOやCTOがニュースを読めば、こう自問するはずだ、『わが社もやらねば』と」

そして、彼らにとってAPIを構築するならMashapeWebshellなどのサービスを使う方が簡単だ。Doyleは、自ら立ち上げたKeyholeが買収された後の3年間をGoogleで過ごした。Googleでは、Google EarthとGoogle Mapsの開発に関わった。

「われわれは地図を軽量なJavaScriptとして公開した」とDoyleは言った。「一種の埋め込みコードのようなものだと考えた。クールですばらしいと思っていたが、あまりの普及の早さにショックを受けた。」

Google Mapsを広く利用されたのは、使いやすかったからだとDoyleは言った。デベロッパーが洗練されたアプリを簡単に作るしくみを組み込んでおくことは、今や最良の慣行だ。

複雑さは避けられない

しかし何もかもが簡単とはいかない。開発が複数のAPIにわたるにつれ複雑さが待ち構えている。MuleSoftはこの穴を、同社のAPIhubで埋めようと考えている。

先週私が書いたように、MuleSoftにとってProgrammable Webとの提携は、同社が〈APIのためのGithub〉と呼ぶAPIhubをProgrammable WebのAPIデータベースと統合し、関連市場でメディアの注目を集めるための好機だ。Programmable Webにとっては、同社のAPIデータベースをMuleSoft APIhubプラットフォームを使ってアプリを開発するコミュニティーへと広げ安定した環境を作り出すことができる。この統合プラットフォームによって、APIの組み込みを容易にしコミュニティーでの協業を促進できると同社は期待している。

アプリケーション・ライフサイクル管理(ALM)のインテグレーター、Tasktop Technologiesは、ソフトウェアのライフサイクル管理プロセスの中で異質なツール群を結び付ける、Software Lifecycle Integration(SLI)というオープンソースの取り組みを開始した。このプロジェクトはオープンソース・プロジェクトのEclipse-Mylynの一部となりM4と呼ばれている。

TasktopのCEO・共同ファウンダー、Mik KerstenはSLIについて、異なるツール間でのリアルタイム同期を可能にする汎用データメッセージバスとして機能し、コードに問題が発生した時にはすぐに対応できる、と評価している。APIエコノミーの発展と共に生まれてくるのが、下支えとなるこうした統合プラットフォームだ。過去2週間にわたる数々の買収と出資は、モバイル機器だけでなくわれわれの生活にある物事ともつながるアプリの開発を真に簡単にするためには、この複雑さを解決する必要があることを示唆している。

[原文へ]

(翻訳:Nob Takahashi)


Web上のペイメント(支払決済)には共通APIがあるべきだ, と頑張るMozillaがFirefox OSに実験的実装

Mozillaはペイメントベンダ(payment vendors, Paypalなど)やWebの標準規格団体W3Cに働きかけて、支払決済の 共通APIを作ろうとしている。それはデスクトップとモバイルの両方で使える、使いやすくてセキュアなAPIだ。Mozillaはすでに、実験的なJavaScript APIをスマートフォン用のFirefox OSに実装している。それは最終的に、Webアプリケーションが支払を受け取るための共通APIになるものだ。支払を取り扱うための共通のAPIを複数のペイメントベンダが実装すれば、デベロッパやパブリッシャーにとって新しいビジネスモデルが開かれる、とMozillaは主張する。

この新しいAPI、navigator.mozPay()は、MozillaによるとGoogleのWallet for Digital GoodsのAPIを参考にしており、まずFirefox OSに実装されてから、その後Firefox for AndroidやデスクトップのFirefoxにも加わる。今のきわめて実験的で不完全なAPIでも“Firefox OSフォーンの上でライブの支払を十分に処理でき、急速に実用レベルでの採用が進む”、とMozillaは期待している。

しかし疑問なのは、ユーザやデベロッパにとってはPayPalStripeがあれば十分で、オンラインの支払決済はそれほど重大な問題ではないのに、なぜMozillaがことさらそれを取りあげるのか、だ。それは、Mozillaの主張では、あらゆる支払サービスにおいてAPIが統一されていれば、個々のWebアプリケーションを使っているユーザに選択の自由が生ずる。また現状では、ユーザも企業もクレジットカード情報という重要な個人情報を扱わざるを得ず、Webという混雑した環境で事故や事件に遭わないことはつねに、運を天にまかせた結果でしかない。言い換えると、ユーザ自身が自分のセキュリティをコントロールできない。

navigator.mozPay()ではデベロッパが、彼/彼女が選んだペイメントプロバイダをを認可でき、きわめて単純率直な方法で支払を処理できる。それはクレジットカード情報の交換ではなく、(ローカルな)トークンの交換処理になる。

今のバージョンのAPIを実装して試してみたい人は、ここへどうぞ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


HTML5対応アプリケーションがオフラインデータを複数のデバイスに亘ってシンクできるAPIをGoogleが提供

chrome_canary

HTML5の便利なところは、Webアプリケーションがデータをローカルに保存できて、ユーザはオフラインでもそれを見られることだ。そしてGoogleが今日(米国時間2/15)披露したChromeの新しいAPI、SyncFileSystem APIは、HTML5のスペックにすでにあるものと似た、アプリケーション固有のサンドボックス的ファイルストレージシステムを提供する。このAPIのおもしろいところは、Google Driveによるクラウド上のバックアップサービスを利用して、複数のクライアント間でデータを自動的にシンクできることだ。

今このAPIが使えるのは、Chromeのきわめて実験的なバージョンであるCanaryにおいてだけだが、数か月後には通常の安定版Chromeにも実装されるだろう。

Googleも言っているが、これはデベロッパがクラウド上の任意のドキュメントにアクセスできるためのAPIではない。オフラインデータを複数のマシンにまたがって保存し、シンクするだけである。

そのドキュメンテーションでGoogleが標準的なユースケースとして挙げているのは、“ユーザが生成したデータ(やそのほかのバイナリデータ)をキャッシングなどの目的でローカルにオフラインで保存するが、アプリケーションがそのデータをクラウドのストレージに保存/シンクして、同じデータを異なるクライアントたちにも可利用にしたいとき”、だ。

現在このAPIは、バックエンドのストレージサービスとしてGoogle Driveだけをサポートするが、将来はデベロッパに、ほかのサービスも使えるオプションを提供するらしい。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

複数(20あまり)のアクセス分析サービスのAPIを簡単に呼び出せるSegment.io

segmentio-logo

Segment.ioは、Y Combinatorが育てたアクセス分析系のスタートアップだ。その売りは、デベロッパが複数のアクセス分析サービスのAPIを自分のアプリケーションに統合できること。今サポートしているのは、20のアクセス分析プロバイダで、その中にはもちろんGoogle Analytics、KISSmetrics、Mixpanel、Chartbeatなどの有名どころもある。またHubSpotやSalesforceのような、アクセス分析専業というより、企業向けの経営〜マーケティングサービスも含まれる。

クライアントサイドとサーバサイド両方の分析をサポートするが、近くモバイルにも対応する予定だ。

ファウンダPeter Reinhardt、Ilya Volodarsky、Calvin French-Owenの三名はMITのルームメイト、四人目のIan Storm Taylorandはロードアイランドのデザイン学校出身だ。四人とも大学〜学校をドロップアウトしてY Combinatorの2011年夏の育成事業に参加した。最初はGoogle AnalyticsやKISSmetricsに対抗するプロダクトを作るつもりだったが、自分たちのプロダクトに乗り換えてくれる人はそう簡単にいない。しかし彼らが作っていた、分析サービスとAPI呼び出しを合わせたようなライブラリAnalytics.jsは好評だったので、それをオープンソース化してGitHubに載せた。

“そのオープンソースバージョンは、坂を転がり落ちる雪だるまのように勝手に成長していった”、とReinhardtは回顧する。“そこで、われわれも悟った。デベロッパたちが欲しているのは、ビューティフルでシンプルな分析APIなんだ、と”。方向転換は12月に行われた。そのときオープンソースバージョンのユーザは1800名いたが、それはそのまま引き継いだ。そして12月からは、有料バージョンの開発を開始した。今日(米国時間1/25)現在では数千の登録会員がおり、300あまりの現在進行中のプロジェクトが、このサービスを利用している。

難しいのは、アクセス分析に関してはAPIに標準性がなくて、各社ばらばらであることだ。リンク連鎖追跡が得意なのがあれば、カスタムイベントの追跡が得意なのや、メールのターゲティング専門みたいのもある。“デベロッパは、これらのAPIを全部ながめ渡して、自分の目的にどれとどれを使えるか判断しなければならない。それは彼らにとって未知の世界だから、悪夢のような作業になる”、とReinhardtは言う。

そこでSegment.ioでは、単一のシンプルなAPIがすべてのアクセス分析プロバイダをカバーするようにしている。APIの加除も簡単にできるので、デベロッパの時間を大いに節約する。Reinhardtによると、Segment.ioを使えば、自分のアプリケーションにアクセス分析の部分を盛り込む作業が2時間以内で終わる。SalesforceやMarketoのようなエンタプライズサービスのAPIによる統合は、もっと大きな時間の節約量になる。“連中のAPIを直接使おうとしたら、それは黴の生えたようなSOAP XMLだからね。今のデベロッパはRESTしか使わないのに”。Segment.ioのユーザの中には、以前は統合に数か月を要したが、今では数時間で済む、という人たちもいる。

Segmentio-example

火曜日(米国時間1/22)に同社は、これまでのブラウザ直接のJavaScriptライブラリに加えて、RubyやNode.js、Python、Java、それに.NETから呼び出せるライブラリをローンチした。今は、ユーザからのリクエストの多いPHP用を制作中だ。また、サポートするアクセス分析プロバイダも、週に2〜3ずつ増やしていく。来週は、Pardotが加わる。

同社からホストされるクライアントサイドのライブラリ(主にAnalytics.js)は無料だが、サーバサイドのライブラリは有料だ。最低料金の月額30ドルではサーバサイドのAPI呼び出し100万回まで、150ドルでは1000万回までだ。HubSpot、Marketo、Omniture、Salesforceなどエンタプライズ向けの統合は150ドルの方の有料サービスに含まれる。なお、メールのサポートは30ドルでも150ドルでもどちらにもある

integrations_small

Segment.ioが提供する価値は、開発時間の節約だ。しかしもっと広い意味では、アプリケーションがよりデータ駆動型になるというメリットがある。Reinhardtはそう主張するが、それは、シンプルなAPIをちょっと使っていろんなアクセス分析を呼び出すだけで実現するのだ。“これまでは、デベロッパが自分のアプリケーションの中で複数のアクセス分析の結果を利用しようとすると、たいへんな作業になった。たいへんすぎて、やらないデベロッパも多かった。でも、これからは違う”、とReinhardtは自負を述べる。

Analytics.jsのユーザ登録はここで。

Segment.ioは、NEA、General Catalyst、およびそのほかのエンジェル投資家たちから計60万ドルのシード資金を調達している。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))