APIを利用したり、提供する中で良くあがってくる問題を紹介します。従来のシステム開発手法と異なるために、問題もまた特徴的です。それらは単に問題として終わらせるのではなく、APIらしい解決方法を考える必要があるでしょう。 トランザクション APIを提供していて最もよくある問題がトランザクションではないでしょうか。この解決法は幾つかあります。 トランザクションが不要な設計をする トランザクションIDを用いる 有効期限付きデータロック トランザクションが不要な設計は最もベストな選択と言えます。実際、システムを開発していて必ずしもトランザクションが必要という場面は多くありません。アイディア次第で解決できるのですが、RDBMSにおけるトランザクションはとても便利なのでつい頼ってしまっていないでしょうか。 また、逆にトランザクションが必要な場合にそれらの処理をひとまとめにしたAPIを提供するという方法があります。その場合はRDBMSのトランザクションが使えますので安心です。 トランザクションIDを使う方法はシステムの複雑化を招く傾向があります。トランザクションを自作するのに匹敵するかも知れません。データのロック、前のデータの保存、ロック解除、データを戻す処理などを自分で作るのはとても大変ですし、不具合があると大きな問題になる可能性があります。 そもそも商品の在庫引き当てなどの場合、行単位でのデータロックで対応できる可能性があるでしょう。その上で5分間などのロック有効期限を設けることで、その間に決済処理を行ったり、失敗した場合にはロックを解除するといった処理にするのが良いかと思います。 ネットワークコネクションが増える RESTfulなAPIではデータモデル一つに対して一つのURIが割り当てられます。そのため、3つのモデルを操作する場合には3つのネットワークコネクションが必要になります。これはスマートフォンアプリなどでは大きな問題になります。 解決策としては、 ネットワーク接続の非同期化 複数処理の同時実行 があります。ネットワーク接続の非同期化は最も簡単な方法で、プログラミング側で対応できます。ただしネットワークコネクション数は変わりませんし、サーバへの負荷が高まる傾向があります。 後者の複数処理の同時実行はバッチ処理化です。3つのモデルに対するリクエストをまとめて一回でリクエストできるようにします。これはプロキシサーバを設け、そのサーバがリクエストを3つに分割してAPIリクエストを行ってもらうことで解決できます。プロキシサーバでは返ってきたレスポンスを一つに結合して返す必要があります。なお、この方法はリクエストの結果を受け取って処理判定して別なリクエストを行う場合には使えません。 例えば顧客情報と取引履歴、サポート対応履歴などを取得して画面に表示する場合、これらの情報を一回のHTTPリクエストとレスポンスだけで受け取れるようになります。 相互通信 APIは一般的にサーバへのリクエストとレスポンスで成り立っています。そのためサーバ側からクライアントに対してリクエストを行うのには向いていません。解決策としては、 WebSocket/MQTTの利用 WebHooksの利用 があげられます。WebSocket/MQTTは相互通信のプロトコルですが、環境によってはバッテリーの消費などが大きくなるかも知れません。WebHooksはクライアントとサーバが常時繋がっている必要はありませんが、クライアント側がHTTPアクセスを受け入れている必要があります。 スマートフォンアプリの場合はプッシュ通知を使い、それを受け取ったタイミングでAPIを叩いてもらう仕組みが使えます。 通信断 APIの処理に時間がかかっていたり、ネットワーク環境が不安定な場合にネットワークが途絶えるリスクがあります。データの取得であれば再度取得すれば良いだけですが、データの登録や更新が伴う場合は大きなリスクになります。 この問題はサーバとクライアント間で処理IDを設けることで、お互いの処理IDを交わすことで通信断した時の処理が終わっているかどうかを確認することができます。そして、クライアント側では処理する内容を記録しておき、オンラインになった時に再開できる仕組みにしておく必要があるでしょう。 CORS Webアプリケーション向けにAPIを公開している場合、ドメインを越えたCORS問題が話題になります。無条件に解放してしまうと思いもしないサイトからアクセスが来る可能性があります。できれば適切に許可を出したいところです。 解決策としてはOAuth2を用いてアクセス元に対するパーミッションを適用することです。アプリケーションごとに公開ドメインを設定し、適切にフィルタリングできるようにしましょう。 APIを提供すると、通常のWebアプリケーションや業務システムではなかった問題に遭遇することがあります。APIらしい設計であったり、クライアント側とのデータ送受信方法を考える必要があるでしょう。

Webサイトやサービスに地図を表示させたいと思った時に便利なのが地図APIです。今回は、無料で利用できる（条件に依っては有料の場合あり）地図APIをまとめてみました。 Google Map API GoogleMapを表示できるAPIサービス。Googleの用意した豊富なMapAPIサービスを使用できる。マニュアルは一部英語だが、丁寧に解説されている。標準プランの場合、1日の表示回数が制限内であれば無料になる。プレミアムプラン（有料）の場合、年間契約でサポートなども付いている。 Yahoo Javascript Map API Yahoo！ロコと同じ地図が表示できる。マウスでドラッグできるJavascriptで動かせる地図のAPI。雨雲レーダー情報を重ねて表示できる機能あり。他にスタティックバージョン・スマホ用（iOS版、Android版)もあり。使用にはYahoo Japan IDとアプリケーションIDの取得が必要であるが、無料。使用方法についてweb上で丁寧に解説されているので、初めて地図APIを使う人にも向いているサービス。 いつもNAVI API ゼンリンデータコムの法人・商用向け地図APIサービス。「渋滞情報」「路線図検索」などゼンリンの豊富な検索サービスを使用できる。電話サポートや「開発者向け情報提供サイト」があり、ユーザーサポートが充実している。5000PV/月以内の場合は無料利用可能。 電子国土web 国土地理院が提供する地図APIサービス。利用目的により、無料で利用できる。地図を利用したサイトを開設した場合、報告が必要。 Open Street Map 自由に参加し、自由に編集し、自由に使用できる地図版Wikipediaと呼ばれるオープンソースの地図。APIも提供している。 Bing Maps: Choose Your Bing Maps API Microsoft社の提供するBing MapのAPIです。試用は90日間、年間12.5万トランザクションまで無料で利用できます。それ以上は有償ライセンスを購入する必要があります。 スマートフォンが広まるのにあわせて位置情報データも増大しています。取得した位置情報を地図上にマッピングしたり、ルート計算、距離測定などに利用ができます。地図は現実世界にも近い存在なので、利用できる場面は多いでしょう。

企業としてAPIを提供し、かつそれをビジネスで活用していこうという動きが出始めています。今はまだスタートアップをはじめとする小規模な企業か、クラウドベンダーなどのIT系企業で取り入れられている動きですが、徐々にそれ以外の企業においても採用されつつあります。 今回はそんなAPIをビジネスで使うことによる新しいチャンスや事業拡大を目指す方法について紹介します。 多面的展開を前提に考える これまでのWebサービスのように、PCのブラウザ向けだけに情報を提供するのであればAPIを提供する意味がありません。昨今、デバイスの種類は急激に増加しており、提供形態もまた増えています。それらを認識し、多面的展開を目指すべきです。 分かりやすいところではスマートフォンやタブレットなどのスマートデバイス、サーバサイド連携、IoTデバイス、Webブラウザの機能拡張などが考えられます。情報の発信先を限定しない観点が必要です。 見通しの良い、保守しやすいシステムへ システムは最初に開発した時には分かりやすくとも、徐々に手を入れていく中で分かりづらく、負債へと変わっていきます。これはシステムが表示部分まで担っている場合に起こりがちです。 API化するということは、システムの表示部分を切り離すということです。すべての表示処理（アプリの画面やWebブラウザなど）はそれぞれのデバイスに任せることができます。また、iOSとAndroidなどで発生する特有の処理はアプリ側で担うことになりますのでロジックもすっきりとさせることができます。 保守しやすいシステムはシステムの運用コストを下げ、新しいビジネスの変化にも追従しやすくなるでしょう。スマートフォンに変わる新しい仕組みが登場したとしてもすぐに対応できるはずです。 システム連携の工数削減 企業間連携や提携を通じて情報の送受信が発生する場合、APIがあるとないとで大幅に工数が変わってきます。特に自分たちだけがない場合、仕様を相手に合わせて設計することになるでしょう。これは相手の企業特有のビジネスフローを含んだものになり、他企業との提携には使えないものになるかも知れません。 APIがあれば、そうした工数が一気に削減できます。もしAPIがない状態で企業連携の話が進んだ場合、そこからお互いに話し合って仕様を検討して実装して結合テストをして…といったことをしているとあっという間に1年経ってしまうはずです。それがAPIがあることで、数ヶ月もあれば完成することになります。 最近のビジネスにおいては手動ではなく自動化されることが前提となっているため、APIの有無によって完了までの時間やその後のスピード感がまったく変わってくるでしょう。 複数企業との提携が容易に APIは自社のビジネスフローを確立するものになります。全く足りない機能があれば追加開発する必要がありますが、そうでない場合はAPIを利用する側がロジックを組んだ上で利用します。つまりAPIが標準フローを担うのです。 標準フローができていれば、後は水平展開していくだけで企業提携が進められるようになります。 トレタ、 POSシステム5社と提携　 シームレスなデータ連携を実現する 「トレタPOSコネクト」を3月1日リリース はまさにその典型と言えます。 ビジネスにおけるAPI利用のイメージは、Webブラウザ以外への情報発信先の拡大、他企業との提携などの利用先拡大と言ったものになるかと思います。つまりAPIを単に作るだけでは意味がなく、APIを使って何をするかが大事ということです。そのためにはAPIありきではなく、ニーズありきで考えた上で、APIという自動化、システム化を担う技術をどう組み込んでいくかが重要になるでしょう。

APIを使った開発、運用でよくあるのが突如としてアクセスできなくなるという問題です。今回はその際に関係する技術と解決手段を紹介します。 自社ネットワークの問題 APIは問題がなくとも、自社側のネットワークに問題が発生していることがあります。LANカードの不具合、ネットワーク設定のミス、ルータ/ファイアウォールの不具合、ケーブルの破損などが考えられます。 外部ネットワークの定期的なアクセスチェックはもちろんですが、内部ネットワークについてもきちんと確認するのが良いでしょう。こういった不具合の問題として、不具合を通知するメールも送信できなくなることです。不具合発生時の通知はもちろん、通常運用時にも定期的な通知を行うのも手です。また、別ネットワークからの生存確認を行うシステムの導入もお勧めです。 DNSエラー ネットワーク周りでよくあるのがDNSの問題です。自社運用の場合はもちろん、ドメイン設定のミスなどでアクセスできなくなることがあります。この場合の問題としては、DNSには設定のキャッシュがあるので問題発生の確認が遅れてしまうことです。 APIからの応答がない APIへリクエストを送ってもレスポンスがない場合、サーバが完全に停止しているか、処理が重たいために遅延している可能性があります。利用する際に適切なタイムアウトを設定しておかないとリクエストが他のキューと合わさって多重化したり、ハングしてしまう可能性があります。 APIのレスポンスに対する品質を予め確認しておいたり、計測しておくことでレスポンスの悪化を予め知ることができます。また、5秒程度でタイムアウトするようにしたり、前のキューが終わっていなかったらアクセスしないように制御します。 40X系のエラーが返ってくる 存在するはずのエンドポイントから404エラーが返ってくるとすれば、アプリケーションサーバが止まっている可能性やAPI自体が削除されてしまった可能性があります。401の場合は認証エラーが多いので、キーを再生成した可能性があります。 一般的に40X系のエラーレスポンスはシステム上の正しいエラーであることが多いので、コードの見直しを行うのが良いでしょう。 50X系のエラーが返ってくる 503はシステムエラーであったり、50X系のエラーはシステムの例外エラーであることが多いです。これは予期せぬエラーになりますのでAPIのテストが不十分であったり、データベースやストレージで問題が発生している可能性があります。API提供元への問い合わせが必要でしょう。 APIでのエラーはシステムの連鎖的不具合につながる可能性があるので、それぞれの問題の切り分けによって正しく判断し、素早い対応が求められます。ただし利用する側としてもエラーが発生することを予め見込んだ上で作り込んでおくのが大事でしょう。

レストランやアパレルなど、殆どの店舗で導入されているのがPOS（Point of Sales）システムです。そんな店舗ビジネスの基盤とも言えるPOSシステムにおいてもAPI活用が広がっています。 今回はそんなPOSシステムで使えるAPIをまとめました。 Orange API タブレットを使ったPOSシステム、EC-Orange POSが提供しているAPIです。売り上げ、商品、在庫、顧客情報を連携できるようになっています。既存の基幹システムとの連携などが想定されています。 スマレジ iPhone/iPadを用いたPOSレジシステム、スマレジで公開されているAPIです。売り上げ、在庫、商品データなどが取得できます。オプションにより会員情報も取得できます。 また、WebHooksにより商品、会員、在庫情報などが更新されたタイミングでHTTPリクエストを飛ばすこともできます。 ユビレジ iPadを使ったレジシステム、ユビレジの公開しているAPIです。売り上げデータのダウンロード、メニュー編集、顧客データの編集などユジレジでできることのほぼすべてがAPI経由で可能です。 ユビレジ for Salesforceという仕組みを使うことでユビレジの売り上げデータをSalesforceへインポートできる仕組みもあります。 Omnivore.io レストラン用のPOSシステムを提供しているOmnivoreのAPIです。商品、オーダー、メニュー、支払いなどすべての機能がAPIから操作できるようになっています。 poscube iPadを使った飲食店専用のPOSシステムを提供しています。注文データや注文履歴、商品データ、テーブル状況と言ったデータをAPI経由で利用できます。空席状況の確認などにも利用できます。 Revel Systems POS iPadを使ったPOSシステムを提供しています。APIを介して全データへのアクセスが可能とのことです。 Point of Sale - Developer API | Power your App with eThor 注文や支払いへのアクセスができます。Facebookからの注文にも対応しているようです。 Shopify POS App SDK Shopifyは元々ECショップを作成できるサービスでしたが、POSシステムも提供するようになっています。POSアプリを提供する訳ではなく、SDKを提供する方法をとっているようで、自分でPOSシステムを組むという形になるようです。 最近ではiPadやタブレットを使ったPOSアプリがたくさん出てきています。そうしたアプリではAPIを使うのが基本になるので、パートナー向けに公開することでAPI公開が実現できます。 多くは基幹システムとの連携に用いられるようで、まさにビジネス向けのAPIと言えそうです。

APIは“Web API”と呼ばれることが多いので、Webアプリケーションと関係が強いと感じられるでしょう。しかしAPIの活用される場所はWebだけに留まらなくなっています。その一つがスマートフォンアプリです。 iOS/Androidを中心としたアプリストアでは300万を超えるアプリが登録されています。この殆どがネットワーク機能を使っており、それらのネットワーク機能はAPIを利用しています。今回はそんなスマートフォンアプリとAPIの関係について紹介します。 多くがプラットフォームまたはプライベートAPI アプリで使われるプラットフォームのAPIとしてはFacebookやTwitter、GitHub、GoogleなどのOAuth認証であったり、DropboxやiCloudなどのストレージAPIがあります。通常、こうしたAPIだけで構成されるものは多くなく、独自のAPIを組み合わせてアプリとしているものが多いです。 そして独自のAPIはオープンになっておらず、プライベートなAPIとして提供されています。アプリはWebアプリケーションと異なりCORS（Cross-Origin Resource Sharing）を気にせずデータの取得、更新ができるのがメリットと言えます。 ビジネスロジックを隠蔽 APIを開発する場合、その多くは細かいビジネスロジックまでサーバサイドで処理を行います。アプリはビューであったり、ユーザの入力データを受け付ける目的で利用します。なるべくビジネスロジックは持たせないのが一般的です。 理由としてはiOS/Androidへの素早い対応が期待されるからでしょう。両プラットフォームで同じロジックを実装するのであればAPIとしてサーバサイドで実装し、アプリはそれを呼び出すだけにした方が工数が減ります。そのため、プライベートAPIはそのアプリならではのニーズに合わせて設計、開発されます。 SDKを利用 プラットフォームのAPIを使う場合、その多くはプラットフォームが提供しているSDKを使います。それによってAPIを実際にコールする部分は隠蔽され、より使いやすい形でデータを操作できます。 プライベートなAPIの場合、利用するアプリが限定されるのでライブラリとして再利用性を高める程度に留まっていることが多いようです。逆にAPIを他のアプリでも使ってもらおうと思うならばSDKの開発は必須と言えるでしょう。 多くがRESTfulまたはバッチ APIの呼び出しは多くがRESTful、JSONで返却されるようになっています。RESTfulで問題になることが多い、トランザクションが使えないと言った問題は、サーバサイドのロジックで処理するプライベートAPIで解決することが多いです。 一般的にRESTfulでは一つのリソースに対する一つの操作を1リクエストとしています。しかしこれはネットワーク通信回数を増やす傾向にあるため、アプリの動作が重たく感じられてしまいます。 そこでバッチ処理として複数のAPI操作を一回のリクエストにまとめる方法があります。この方法はAPIサーバの前にプロキシサーバが立ち、それがバッチ処理を順番にリクエストし、結果を結合して返すといった処理を行います。 セキュリティに注意 アプリとAPIサーバ間の通信はほぼ筒抜けです。もしSSL/TLSを使っていたとしてもアプリ側に設定を行うことで盗み見ることはできます。その結果として、ゲームアプリで言うところのチートなどが行われます。 そのため、通信内容は見られることを前提として誤ったデータが混入されるのを防ぐ仕組みを整えておきましょう。SSL/TLSは基本としつつ、サーバ側のロジックでチート処理に対して対策をするのは必須です。 Webブラウザは利用者保護の仕組みが整っています。外部ドメインに対してできる処理が限られていたり、サーバ側が許可しなかったらiframeやAjax処理もできないようになっています。 対してスマートフォンアプリは自由度が高くなっています。APIを提供する側としても、アプリをターゲットとするならば今回あげた要件は必須になってくるでしょう。

Mashup Awardから見るよく使われるAPIの条件とは？ Mashup Awardは毎年行われているAPI活用コンテストです。すでに11回も行われており、毎年多くの作品が生み出されています。 今回は 2015年のMashup Awardにて最も使われたAPIベスト5 を見つつ、APIが使われるために必要な条件を紹介したいと思います。 Microsoft Azure Microsoft社では数多くのAPIを提供しています。特にIaaSとしてのAzureプラットフォームが人気のようです。2009年から3年連続で最も使われているAPI第一位を守り続けているとのことです。 Twilio for KDDI Web Communications 簡単にネットと電話をつなげられるAPIとして有名です。海外のハッカソンでも人気のAPIとして知られています。 ニフティクラウドmobile backend スマートフォンアプリを作る際に必要なサーバサイドの機能を提供するサービスです。ユーザ管理やプッシュ通知、位置情報検索が利用できます。 SendGrid メール送信サービスです。開封率やリンクのクリックトラッキング、テンプレートといったメール送信で必要になりそうな機能が提供されます。 Monaca HTML5を使ってiOS/Androidアプリが開発できるプラットフォームです。Web開発で培った技術を使ってiOS/Androidの両プラットフォームに対応したアプリが開発できます。 pepper ソフトバンク社の販売するロボットです。タブレットを使ってアプリを開発できます。会話をしたり、身振りを使ったりと多彩な動作が可能です。 これらのAPIを見る限り、大枠で2つに分類ができます。 プラットフォーム 開発補助&単機能 プラットフォームとしてはMicrosoft Azure、ニフティクラウド mobile backend、Monaca、pepperがあります。開発補助で使えるのはTwilioやSendGrindになるでしょう。プラットフォームとしては使いやすさやドキュメント、ハンズオンの回数、サポートなど導入までの敷居とその後のサポートが差別化につながっているようです。 開発補助系ではAPI自体が他と違う珍しいものであったり、それを使うことでマッシュアップが魅力的なものになるかが大きな鍵になるかと思います。もちろん、導入の敷居が低かったり、ドキュメントが充実しているのは言うまでもありません。 【発表】最も使われたAPI &（勝手に）DeveloperSupport大賞発表 2015年版 | Mashup Awards によると、サポートやハンズオンの取り組みが手厚いかどうかが結果に表れているようです。つまりAPIは単に作って公開するだけではだめで、積極的に開発者へコミットすることではじめて使ってもらえるようになるのだと考えられます。 APIを公開する企業としては、公開後の動きこそ大事というのが分かるのではないでしょうか。

Parse.comというスマートフォンアプリのサーバサイドを提供するサービスが突如として サービス終了のアナウンス をしました。1年間の猶予があるとは言え、信頼して使ってきた開発者にとっては寝耳に水の出来事となっています。 Parse.comはFacebookに買収されたサービスであり、買収後も継続してサービスを運営してきました。それだけに突然の終了アナウンスはParse.comはもちろん、Facebookへの信頼についても揺らぎかねないものでした。 今回はそんなAPIを使う上での最大のリスクとも言える、提供企業側のサービス運営方針変更に伴うリスクについて紹介します。 サービス終了がありえる 当たり前ではあるのですが、永続的に存在しうるサービスはありません。お気に入りだったWebメディアであったり、ECサイトが閉鎖された経験は誰もがあるでしょう。これらは多くの場合、代替サービスが存在します。 APIの場合、サービス提供側がベンダーロックしているケースが多くあります。その結果としてサービス方針の変更が大きな影響を及ぼすことになります。 サービス終了に限らないリスク サービス終了は最も大きなインパクトがあるかも知れません。しかしそれ以外にもリスクはあります。価格変更（無料で使えていたサービスが有料化したり、価格があがるなど）、サービスメンテナンスや緊急停止などもあります。そのため、サービスを使い続けるとともに、常に代替や自分たちで同等のシステムを構築する方法について模索しておく必要があるでしょう。 信頼できるベンダーの選択 ここでいう信頼性とは、企業が巨大であれば良いわけではありません。大企業にとってはAPIサービスはごくごく小さな事業規模であることも多く、その結果として収益が見込めないと分かるとすぐに精算してしまう可能性があります。 また、収益化されていない、またはする気が見えないサービスも要注意です。APIのアップデート、発信力、コミュニティなどを統合的に鑑みた上で、ベンダーがAPIの提供に本気であるかどうかを判断する必要があります。 リスクヘッジの方法について APIが突然終わることのないよう、常にリスクヘッジを考える必要があります。例えば、 代替サービスの選定 自社開発への移行 契約上の縛り サービスの買収 などがあるでしょう。提供を終了しているサービスは他社への売却を検討している可能性があります。そのため、サービスを買い取ることでリスクをなくすこともできるでしょう。 APIは内部がブラックボックスになっています。それはプログラムもそうですが、運営企業についても外からでは分からないことがたくさんあります。そのため、開発者界隈で積極的に情報を交換したり、市場の推移を見てリスクヘッジを常に考えておくのが良いでしょう。

APIを複数組み合わせて新しい価値を作り上げるのがマッシュアップです。日本では Mashup Awardが毎年開催 されており、数多くのマッシュアップ作品が生み出されています。中にはそれをベースにビジネス化に乗り出す方々もいます。 そこで今回はマッシュアップサービスをビジネスとして考える時のメリット、デメリットについて解説します。 メリット 元になるデータが不要 APIが提供するデータを使うので、手元にデータがなかったとしてもすぐにサービス開発できるのがマッシュアップの魅力でしょう。ホテル、駅、地図、サーバなどあらゆるリソースがAPIを介して利用できます。 少ないリソースではじめられる 例えば位置情報に関連したサービスを考えた場合、ある地点を軸とした周辺情報を返すAPIを使うでしょう。本来、位置情報を使った検索処理は負荷が高かったり、複雑なシステムが必要ですが、そうした開発は一切不要で利用できます。 また、画像変換や天気情報なども複雑なロジックを気にすることなく使えるのが魅力です。自分たちでゼロから構築したら時間も工数もかかる作業ですが、APIを使うことですぐに手に入れられます。 公式では提供できないアプローチができる API提供元でもサービスを運営しているケースは多いです。そんな時にマッシュアップで似たようなサービスを作ってもなかなか流行らせるのは難しいかも知れません。しかしニッチ戦略をとることで十分にメリットあるサービスを作ることができます。 本家にはアプローチしづらい特定の市場向けに作ったり、特定用途に向いたUIを作ることもできます。そうした小さな市場向けに特化するのは公式サービスとしては難しいですが、マッシュアップであれば容易に作ることができます。 相対するサービス同士を結合することも可能 主に比較系サービスを考えた場合、複数の類似APIを組み合わせることが多いでしょう。そうしたサービスもまた、公式では提供しづらいのでマッシュアップならではのアプローチと言えます。 競合が存在するからこそ使える手法と言えるでしょう。利用者にとっては大きなメリットがあるサービスになるので、そこから収益をあげることもできるはずです。 デメリット API提供元の決断で左右される マッシュアップの最大のリスクと言えます。API提供元が突然API提供を止める（またはメンテナンスする）、利用制限をする、APIのフォーマットが変わるなど考えるべきリスクは数多くあります。 こうした潜在的リスクを回避するためにはあらかじめ法人契約したり、SLAが保証されたAPIを選定すると言った工夫が必要でしょう。 権利問題 APIが提供するデータ、画像などは基本的に権利はAPI提供企業にあります。つまり自分たちのものだと言えるデータがないのがマッシュアップのリスクと言えます。例えばAPIが応答不能になった場合を考えてキャッシュしたいと思うかも知れませんが、規約によって禁じているものもありますので注意が必要です。 キャッシュに関連して、API提供元でデータを消したのにマッシュアップ側で残ってしまうケースがあります。ユーザの不満につながったり、最悪の場合刑罰につながるリスクもあります。 真似が容易 マッシュアップはロジックの差になるので、真似がしやすいのがデメリットと言えます。回避するためには自分たち独自のデータを用意するべきでしょう。もちろんマッシュアップされたコンテンツを独自データにすることもできます。 Webサービスは一般的に模倣しやすいですが、マッシュアップでは特にその傾向が高くなります。他社に真似されない、独自の技術やコンテンツを蓄積する必要があります。 マッシュアップはWebサービスを一から作るのに比べると格段にはやく、かつデータの揃った状態で開発ができます。もちろんそれは他社にとっても同様で、すぐに真似されるリスクはあります。 それらのリスクを回避する手段はありますので、リスクを理解した上で進めれば決して問題にはならないでしょう。ビジネスにつながるマッシュアップをぜひ考えてみてください。

API提供をしているのに、なかなか利用が伸びずに悩んでいるというケースを聞くことがあります。総じて提供側に問題があることが多いのですが、なかなか中の人では気付きづらいようです。 そこで今回はAPI提供におけるよくある問題点を挙げてみたいと思います。 APIだけ提供する これはよくあるケースですが、APIを提供すれば勝手に利用が伸びていくと思っているケースです。実際にはそんなことはありません。例えば各言語向けのライブラリであったり、サンプルコードがないと、使ってみたいと思えないはずです。 ライブラリやSDK、Developer Kitと呼ばれる類のソフトウェアについてはなるべくオープンソースで公開しましょう。そうすることで何か困ったことがあってもコードを見つつ、開発者が自己解決できるようになります。 ドキュメントの不整備 APIの最低限のドキュメントしか用意されていないケースも問題です。ドキュメントはどれだけあってもありすぎると言うことはありません。すべてを見る人は多くなく、実際には検索エンジンで探してきてくれることの方が多いはずです。 これはライブラリについても同じで、ライブラリのクラス/APIドキュメントも用意しましょう。これらはJavaDocやPHPDocumentorといったツールから自動生成されるものを使うと良いでしょう。 質問できない どんなによくできたAPIであっても使っていると質問が出てくるものです。そんな時に聞ける場所が用意されていないのは大きなマイナスです。なるべくオープンな場所で聞けるようにしてあげましょう。 そして質問が来たら放置せず、中の人が積極的に答えるようにしましょう。Q&A形式でのナレッジの蓄積は個々だけでなく、それを閲覧している人にとっても大きなコンテンツとなっていくはずです。 汎用性がない APIを見て、どう考えても一つしか使い方の考えられないものも数多くあります。提供側の意図はAPIを通して見えてくるもので、自社の利益ばかり考えるようなAPIは誰も使いたいと思わないでしょう。 かといって、あまり汎用性が高すぎる（何でもできる）のも問題です。中のエンジニアとしての設計技量次第かも知れません。 更新されない APIは作って終わりではなく、定期的なメンテナンスが欠かせません。それを止めてしまったAPIは開発者からもあっという間に見放されてしまうでしょう。 定期的な開発を可能にするのは、APIにビジネス的メリットが見いだせるかどうかにかかっていると言えます。自社と開発者のメリット、そのバランスがとれてこそAPIとしての成功が見えてくると言えるでしょう。 独自仕様 認証が独自仕様であったり、開発が面倒なものを誰が使いたいと思うでしょうか。世の中にはすでにデファクトになる技術がたくさんありますので、そういった流れに乗ったAPI設計を行うべきです。 独自仕様の場合は使いやすくするライブラリが必須と言えます。デファクトがなかったとしても、認証やフォーマット、セキュリティ周りなどにおいて標準仕様を取り入れることはできるはずです。 利用制限が厳しい ビジネス用途でもない限り、利用制限はなるべく撤廃しましょう。もちろん無制限に使える必要はありませんが、1日に数十人が使ったらリミットになってしまう程度では面白くも何ともないでしょう。 ビジネス用途のAPIにおいてもパートナー契約しなければ仕様すら見られないというのでは問題があります。サンドボックス環境を用意するなど、試せる環境は用意すべきです。 APIは通常のWebサービスとは異なり、広め方に苦労することがあるかも知れません。そのためにもまずアンチパターンはなくすべきです。 自社の提供するAPIがこれらに引っかかっていないか、ぜひ見直してみてください。 画像は Crossroads: Success or Failure より。

一般的なAPIはこちらからAPIをコールします。それに対してWebHooksはサーバ側からこちらの指定したURLをコールしてもらう仕組みです。 用途は絞られるかも知れませんが、使い方によってはとても有用です。今回はカテゴリごとにWebHooksを提供しているAPIをまとめてみました。 メール/マーケティング 圧倒的に多いのがこのメールやマーケティング分野です。ユーザが何かアクションしたタイミングで通知代わりに飛ばしてくれるようなイメージです。 The WebHook APIs - WuFoo Webhooks | Campaign Monitor MailChimp | API Docs Webhooks API | Mandrill Webhooks — Mailgun API documentation VerticalResponse - Webhooks API Recurly Developer Hub Webhooks API — FluidSurveys APIs Docs Webhooks - Email Marketing API コミュニケーション 有名なところではSlackがあります。チャットの他、コミュニティなどでもWebHooksが使われているようです。 Incoming Webhooks | Slack Outgoing Webhooks | Slack HipChat - API v2 - Webhooks Jive REST API v3.13 → Webhooks service Webhooks API - NationBuilder 開発 開発系ではGitHubもWebHooksを提供しています。開発スピードを速くしたり、外部サービス（CIなど）と連携する上で必須の機能と言えるでしょう。 Webhooks | GitHub Developer Guide PagerDuty Developer API Reference | Trello Developers Webhooks - Atlassian Developers Eコマース/決済 決済系ではまず対象のサービスをコールして、その後はサーバ側とデータを送受信することで決済データを授受します。WebHooksを使うことでセキュアなデータのやり取りを可能にしています。 Webhook - Shopify API - Developer Resources Webhook | WebPay: 開発者向けクレジットカード決済サービス Webhooks overview - PayPal Developer Webhooks - Stripe API: Webhooks - Chargify Documentation API documentation - Webhooks - SEOshop ストレージ DropboxやBoxなどでもWebHooksを提供しているようです。ファイルの更新時にコールするといった使い方ができそうです。 Developers - Dropbox Box Developer 変更の監視 - Evernote Developers ビジネス ビジネス系は使い方が難しいですが、通常のAPIとはまた違った利用法が生まれるかも知れません。 Person API Documentation - FullContact Vend / Webhooks - Vend Developers Webhooks - shipwire マーケティング系がとても多いのに驚かされます。アンケートの回答やメールマーケティングへの反応をリアルタイムに受け取ることで、オートマーケティングを可能にしているのかも知れません。 WebHooksを使えばこれまでとAPIと逆方向の利用が考えられます。ぜひ使いこなして業務を改善、スピードアップしてください。

APIはシステム連携に用いるもので、24時間365日使えて当たり前といった雰囲気があります。とは言え、人が作るものだけに何らかの不具合が発生する可能性もないわけではありません。 そこで必要になるのがステータスの確認ページです。最近では有名なWebサービスでは大抵APIやサービスステータスページを公開しています。今回はそうしたAPIステータスページを作るためのソフトウェアやサービスを紹介します。 owainlewis/status Scalaで作られたシステムです。登録したURLに対してレスポンスが返ってくるかチェックをします。エラーが発生した際に、その結果をSlackに対して飛ばす機能があります。 デモページ DoESLiverpool/status ちょっと変わった見え方のステータスページになります。オンライン、または稼働中というラベルが強調されていますので生死確認は分かりやすいでしょう。各ステータスをクリックすると、細かなデータが分かるようになっています。システムはNode.js製です。 デモページ Stashboard: The open source status dashboard AmazonやGoogleのステータスページをまねた作りになっています。Twilioが開発しています。システムはGoogle App Engine上に立てる仕様になっているのは、まさにGoogle App Engine向きな使い方と言えそうです。 デモページ Cachet - The Open Source Status Page System かなりリッチなUIのステータスページが作れます。公開できる情報を伴ったダッシュボード的なシステムと言えそうです。フィードも公開できますので、購読しておくことで履歴の蓄積もできます。デザインはスマートフォン対応です。 デモページ StatusPage.io - Hosted Status Pages for Your Company 多くの企業でも使われているステータスページ提供サービスです。グローバルにUS/EUなどからアクセスしてくれるので、一部地域ではうまく接続できないといった問題にも対処できます。月額29ドルからの有料サービスとなっています。 いかがでしょうか。オープンソース・ソフトウェアであれば自分たちでサーバを用意してデプロイすれば良いでしょう。ただし同じ地域に用意するのは意味がありません。EUやUSなど遠くに置く必要があります。Google App EngineであればGoogleのネットワーク化にありますので離れた存在となりそうです。 StatusPage.ioを使えばより手軽にステータスページが用意できます。APIを公開する際にはこういったページも忘れずに用意するようにしましょう。

Webシステムにおいてネットワーク速度は常に問題になります。特に最近は動画コンテンツが増えているため、ネットワークへの投資を控えるとユーザが大いにストレスを感じてしまうでしょう。 そこで今回はCDNをまとめて紹介します。特にAPIを提供しているものになるので、システムと連携してダイナミックにコンテンツを配信できるはずです。 CDN by MaxCDN | Experts in Content Delivery Network Services MaxCDNのAPIでは各種プログラミング言語向けにSDKが提供されています。Python/Ruby/PHP/Node.js/.NET/Goとなっています。これらのSDKを使って、MaxCDNがフルコントロールできるとのことです。 また、GitHubとの連携によって、コードをアップロードするとCDNのキャッシュをクリアすると言った操作もできます。 API | MaxCDN Product Features CDN powered by KeyCDN | Content Delivery Made Easy KeyCDNのAPIはRESTfulに操作が可能です。ゾーンの作成、一覧、更新、削除などがすべてAPI経由で操作できます。CDNのステータスや課金情報の取得も可能です。 KeyCDN API | CDN API Documentation Rackspace: Managed Dedicated & Cloud Computing Services クラウド管理サービスを提供するRackspaceでは独自に提供するCDNのAPIを提供しています。サーバ自体の運用はRackspaceにお任せですが、サーバのレスポンスについて高速化または調整したい時に使えるでしょう。 Rackspace CDN API 1.0 - Rackspace Developer Portal CDN by MetaCDN - Live Streaming - Content Delivery Network MetaCDNは通常のCDNの他、ライブストリーミングに特に強みを置いています。APIからでももちろんライブストリーミングに関する操作ができます。CDN配信するコンテンツの登録や削除と言った操作ができます。 MetaCDN Web Service API Content Delivery Network (CDN) | CDN77.com CDN77ではCDNの操作はもちろんのこと、課金、データセンターのロケーション、請求書、ログ、レポート、ストレージとストレージの場所に関するデータの取得、操作がAPI経由でできるようになっています。 Api | CDN77.com jsDelivr - A free super-fast CDN for developers and webmasters 誰でも使える無料のパブリックCDNであるjsDelivrのAPIです。データが自由に登録できる訳ではありませんので、登録されているライブラリの一覧やバージョンリストを取得できるAPIとなっています。 jsdelivr/api: API for public CDNs 選ばれる次世代定額CDN｜レッドボックス CDNは一般的に従量課金制ですが、レッドボックスは定額のCDNとなっています。APIではキャッシュの削除に対応しており、正規表現もサポートしています。 定額CDN「エッジキャッシュ」にAPI機能追加！正規表現も正式サポートしました。 | レッドボックス Affordable CDN by CDNsun | Content Delivery Network ライブストリーミングへの対応や1TBあたり45ドル、ソフトウェアダウンロードサポートなどの特徴があります。APIではサービス、ストレージ、ロケーションなどが操作できます。 CDN API | CDNsun Content Delivery Network (CDN) & Cloud Computing Services | Akamai CDNの最大手として知られるAkamaiもAPIを提供しています。開発途中のAPIも多く、力を入れているのが分かります。その数も多く、運用からレポーティング、決済まで幅広く対応しています。 API Catalog Amazon CloudFront CDN （コンテンツ配信とストリーミング） | AWS Amazon Web Servicesが提供するCDNです。Amazon S3と連携しており、WAFなど他のAWSと連携できるのが強みと言えます。動的なコンテンツ配信にも対応しています。 Amazon CloudFront CDN （コンテンツ配信とストリーミング） | AWS CDNについては各サービスとも大きな差異はないと思いますが、APIについては提供範囲が大きく異なるようです。何でも高速配信というのではなく、より細かく指定できたりキャッシュのクリアができるものを選ぶのが良さそうです。 CDNは一般的に従量課金なので、全コンテンツをCDN化すると料金が高くなってしまいます。その点もAPIを使って細かくマネジメントすると良いのではないでしょうか。

自社データをAPIとして公開することを考えた際にポイントとなってくるのが、そのAPIによってどんなメリットがあるのかということでしょう。企業としてAPIを公開する以上、単に公開して終わりという訳ではありません。そこには新しい収益源になる可能性があってこそだと思われます。 そこで今回はAPIを使った主な収益化の方法について紹介します。 データの販売 自社の持っているデータが貴重なもの、または特許や資格が絡むといった理由で他の企業との差別化が図れる場合は、そのデータ自体を有料で販売する方法が考えられます。 例えばIPアドレスから地域情報を返すデータベースを持っている Digital Element 、 どこどこJP であったり、天気データを販売している 天気予報API もあります。地図データをGoogleマップに提供しているゼンリン社もよく知られています。 既存サービスのアドオン すでにWebサービスを提供しており、APIは有料で利用できるようしているサービスも多数あります。一般ユーザであればWebサービスでも十分ですが、企業が大量の処理を自動化する中ではAPIを使いたいというニーズがあります。そこでAPIを有料として提供します。 自動化、スピードアップなど企業でよく発生するニーズに対応できるようになります。APIを追加機能とすることで、課金ターゲットにすることができます。 既存サービスの機能拡充 もし自社で何らかのWebサービスを提供している場合、さらに機能拡充を狙って他社のAPIを使うことが考えられます。単体機能では使いづらくとも、自社のサービスと合わせることで魅力的になるのであれば取り込む価値があるでしょう。 Yahoo空席レーダーではトレタ社のレストラン予約データを使って提供されています。Yahoo空席レーダー自体は有料ではありませんが、ユーザの囲い込みに大いに貢献しているサービスになります。 他の企業との提携 他の企業との提携を考えた場合、今はAPIを用いた自動化が当たり前になっています。むしろAPIがない場合、提携も進めづらい状態と言えます。相互にAPIがあるからこそ、自動化ができたりインタフェースのすり合わせもスムーズに行えるようになります。 APIを汎用的に設計、開発することで一社のみならず複数企業との提携も容易に行えるようになります。さらに大手との提携が進めば自分たちのAPIが業界標準となっていくことも考えられるでしょう。 機能の販売 APIで提供されるのは何も自社データに限りません。画像加工であったりグラフの出力などデータ加工を行うAPIも有料で提供されることがあります。その場合、あまり簡単なものであると他社に簡単に模倣されてしまいますので、自社独自の技術が合わさってこそ収益化も考えられるようになります。 例えばクラウド上で動画を変換するサービスであったり、3Dモデリングを行うサービスもあります。大量のリソースを使うサービスであってもクラウド上の基盤を用いることで安価、かつ高速に処理できるようになります。 APIを公開しただけではなかなか利用が伸びるものではありません。利用が伸びない中ではAPIの追加開発も困難になります。Webサービスと異なり、UIがない中でのサービス提供となると打ち出し方、ビジネスモデルも変わってくるでしょう。 B to BにおいてAPIを開発する際にはまず適切なビジネスモデルを組み上げた上で行わなければなりません。もしそれがうまくいったならば、自社の新しい収益源として大いに貢献してくれることでしょう。

ここ半年くらいで一気に注目が集まっている技術ワードがブロックチェーンです。BitCoinで使われている技術として知っている人も多いかと思いますが、ブロックチェーンを限られたネットワーク内で利用する方法が取り上げられています。 ここ最近の動きやブロックチェーン実装についてまとめてみました。 オープンソースによるブロックチェーン実装 オープンソースでブロックチェーンを体感する最も早い方法は BitCoin を使うことでしょう。現在、それ以外でも実装がはじまっています。 Linux Foundation Unites Industry Leaders to Advance Blockchain Technology としてIBM、アクセンチュア、シスコなどを集めて実装を開始しています。このプロジェクトはLinux Foundationの監督下にあります。また、 R3コンソーシアムもオープンソースのブロックチェーン実装を開発 しはじめています。 SaaSとしてのブロックチェーン実装 オープンソースの場合、自社でクラウド環境を組み上げる必要がありますが、SaaSの場合はそういった手間は不要です。 Chain | Enterprise Blockchain Platform NasdaqがChain社と提携し、未公開株式市場でブロックチェーン技術を使うと発表しています（via 金融インフラをブロックチェーンで代替してコストを10分の1に、日本から「mijin」が登場 | TechCrunch Japan ）。 mijin 国内のブロックチェーン実装で、さくらのクラウドと組んで実証実験環境を提供するとのことです。mijin自体オープンソース・ソフトウェアとなっています。 クラウドではマイクロソフトのAzureでもブロックチェーンサービスが開始しています。 Ethereum Blockchain as a Serviceというサービス になります。 イスラエルの企業、Coluもクラウドでブロックチェーンベースのサービスを提供しています。 Blockchain Technology and Colored Coins - digital assets - Colu Coluではbitcoinの情報に加えてメタデータを追加できるとのことで、通貨だけでなく鍵やチケットと言った付加情報を含めたトランザクションができるようになります（via Bitcoinのブロックチェーンに便利なメタデータ層をつけて多様なアプリケーションを可能にするColu | TechCrunch Japan ）。これによりブロックチェーンの可能性が大きく飛躍することでしょう。 企業の動き 企業としてブロックチェーンを商品化する動きもあります。前述のIBM、マイクロソフト、さくらインターネットなどに加えてサムスンも開発を開始しています（via サムスンがブロックチェイン技術を研究、5年以内に製品化目処 | BTCN｜ビットコインニュース ）。国内ではOrb社がブロックチェーン技術を研究、開発しています。すでに SmartCoinという仮想通貨発行サービスを提供 しています。 誰でも簡単に仮想通貨がつくれる、OrbのSmartCoin ブロックチェーン技術はFinTechと絡みつつも、Coluでのメタ情報付与など多くの可能性を持った技術となっています。クラウドとの親和性も高く、APIを通じて自動的にスケールしたり、データのトランザクションを管理するのに使える可能性があるでしょう。 オープンソースによる実装はまだしばらくかかるかも知れませんので、クラウドベースでいち早く体験してみてはいかがでしょうか。

メリークリスマス！ Enterprise APIs Advent Calendar 2015 のラストをかざるのは、Enterprise APIs Hack-Night #3開催概要のご案内です！ 2015/2/10(水) 19:00より、Enterprise APIs Hack-Night #3を開催します。 場所は dots. さんのイベントスペースです。 今回も特にテーマは絞らず幅広くやります。 様々な分野、立場からEnterpriseなAPIについて語っていただきます。 セッション（予定）は以下の通りです。 FintechにおけるAPIとマネーフォワードの取組み（仮） by 株式会社マネーフォワード　泉谷さん APIで作る教育プラットフォーム（仮） by 株式会社リアルグローブ　大畑さん APIだけでフロントエンド開発を可能にした話（仮） by 有限会社バーチャルテクノロジー　竹嵜さん 5分間のLT × 5 by 有志一同（登壇者募集！） 当日は懇親会も予定していますので、ご気軽にご参加ください。 勉強会詳細とお申込みは こちら から。

以前、 IAM API の活用方法についてご紹介しましたが、今回はNTT Comサービスのビジネスプロセスを制御する「Business Process API」の利用シーンについてご紹介したいと思います。 本記事は、 Enterprise APIs Advent Calendar 2015 への投稿です。 Business Process APIとは？ NTT Com各種サービスのビジネスプロセスに関する情報提供、操作を可能とするAPIです。 具体的には以下４つの情報操作を可能とします。 契約情報 サービスオーダ チケット情報 メンテナンス情報 各APIの詳細は Business Process API Docs をご覧ください。 人が介在しない正確なオーダ管理 主にNTT Comのパートナー企業さまでご活用いただきたいBusiness Process APIのユースケースです。 従来、NTT Comのサービスを契約する場合は、営業やコールセンタ等を通じてお申込みしていただく必要があり、専任のオペレータを用意するなどパートナー企業さまにとって大きな負担となっていました。 サービスの申込、変更、解約に関するAPIを開放することで、パートナー企業さまのシステムから直接オーダ処理を実現することが可能になりました。 これにより、パートナー企業さまで専任オペレータを用意する必要がなくなるため、人的コストを削減できたり、手作業によって発生するオペレーションミスをなくすことなどが期待できます。 運用保守の見える化と一元化 NTT Comサービスの工事情報や障害情報、復旧情報を確認するには、専用のポータルサイトへアクセスする必要がありました。 メールやRSSでも情報を受け取ることは可能ですが、お客さまの運用保守システムなどで情報を一元的に管理することが困難でした。 このような状況を改善する目的で開放されたのがチケットAPIやメンテナンスAPIです。これらのAPIを活用することで、お客さまの運用保守システムと連携することが可能となり、NTT Comサービスの運用状況を可視化して利用することが可能となりました。 ホワイトレーベル（ホワイトラベル）提供 Business Process APIを活用すれば、契約情報の管理や運用状況をAPIを介して情報取得することができるため、NTT Comサービスをお客さまブランドでエンドユーザに提供することもできます。 以上のように、Business Process APIを活用することで、NTT Comサービスをより扱いやすくご利用いただくことが可能となります。 また、国内主要通信キャリアにおいて、サービスのビジネスプロセスに関するAPIを公開したのはNTT Comが初です。 Business Process APIは無料でご利用いただけますので、是非みなさまのビジネスにご活用いただければと思います。

見積書、請求書そして納品書などビジネスの場では様々な帳票が利用されています。かつては自社内にサーバがあり、そこから帳票を出力していました。しかし最近ではクラウド型の帳票出力サービスが増えています。 今回はそんな帳票サービスの中でもAPIを用意しているものを紹介します。APIを使うことで基幹システムとの連携や自動化がスムーズになることでしょう。 MakeLeaps API 帳票の作成と郵送まで行ってくれるクラウド請求サービスです。オンライン決済システムも備わっています。 認証APIだけが公開されており、他のAPIについては問い合わせが必要となっています。現在オープンβとなっています。 クラウドで見積・納品・請求書を簡単作成、管理、郵送 Misoca API について · Misoca(みそか) API Webブラウザはもちろんアプリもリリースされている請求書作成サービスです。メール配信、PDF保存、郵送ができます。 OAuth2に対応したアプリケーションが作成できるようになっています。郵送指示や入金ステータスの変更などがAPI経由でできます。 請求書作成サービス「Misoca(ミソカ)」 開発者の方へ｜請求書作成ソフト「MFクラウド請求書」 マネーフォワード社によるサービスで、OAuth2認証に対応しています。取引先の作成や帳票の作成なども含めてほぼ全ての操作がAPI経由で可能なようです。 請求書作成ソフト「MFクラウド請求書」 Zoho Invoice API Zoho社によるサービスですが、今のところ日本語化はされていないようです。請求書、納品書の作成、取引先の管理などがAPIを経由して可能です。 Invoice Software | Online Invoicing Solution From Zoho 2つの連携インターフェース API｜大規模帳票管理｜クラウドシェアードオフィス 帳票がExcel上で設計できるのでプログラマでなくとも手軽に扱えるのが利点です。帳票の郵送も可能です。 既存のWebサービスに電子帳票を作成する機能を追加すると言った使い方もできるとのことです。 クラウド帳票｜大規模帳票管理｜クラウドソリューション｜クラウドシェアードオフィス 帳票の出力枚数が増えると自動化を考えるようになります。クラウドでもそれは同じで何百枚もの帳票をミスなく出力するのは大変なことです。また、売り上げ管理などは自社の既存システムを使っているケースも少なくありません。 帳票サービスを使う際にはAPIが提供されているかどうかを重視した方が良さそうです。

Enterprise APIs Advent Calendar 2015 への記事です。 大学や専門学校ではもちろん、最近では小中学校においてもICTの活用が進んでいます。 ICT活用事例として代表的なものにeラーニングがありますが、eラーニングの仕様については国際的な標準規格が存在し、今日はその一つであるExperience APIについてご紹介したいと思います。 Experience API(旧称：Tin Can API) eラーニングの仕様についてはSCROMという国際的な標準規格が、米国のADLという機関によって策定されましたが、このSCORMに継ぐ世界標準規格として定めらたのがExperience APIです。 Experience APIは、あらゆるタイプの教育経験（学習活動履歴など）を記録するために、教育コンテンツと教育システム間を相互にやりとりするためのAPIです。 略してxAPIと呼ばれることもあるそうです。 Experience APIはRESTベースのインタフェースを備え、データフォーマットはJSONで規定されています。 詳細は APIリファレンス をご確認ください。 （日本語版もあります） Experience APIが策定された経緯 SCORMはLMSにおいて学習履歴を管理しますが、SCORMの規格は色々問題があったようです。 そこで、Experience APIでは、SCORMでは実現できない以下の操作が実現可能になるよう規定されています。 例えば以下のようなことが実現できるようです。（以下、Wikipediaより抜粋） ウェブブラウザ外でのeラーニングの実施 モバイルアプリケーションにおけるeラーニング 教材に対しての、より広い制御 OAuthを利用した高セキュリティ プラットフォームを跨いだ学習：例として、モバイルで学習開始しＰＣで終了 ゲームやシミュレーターにおけるユーザー動作のトラッキング 実世界でのパフォーマンスのトレース チームでの成績管理 教育プランとゴールの追跡管理 その他のシステムのデータとLMSのデータをマージして比較 動画教材等において、どの部分が視聴されているか等の詳細の学習履歴把握 Experience APIに対応したサービス edo-xrs 個人から発生する様々なデータを記録するリアルグローブ社のプラットフォームです。学習記録や医療記録等をはじめとする、あらゆるパーソナルレコードをスケーラブルかつ高速に蓄積することができます。『edo-xrs』は、LRS(Learning Record Store)として、総務省「先導的教育システム実証事業」の学習記録データ蓄積機能に採用されています。 （2015/8/12プレスリリースより抜粋） edo-xrsプロジェクトサイト LRS ( Tin Can ) ジンジャーアップ社の統合ソリューションで、日本でいち早くExperience APIに対応したLRSを開発し、様々なサービスに適用されています。 Experience APIの仕様により、e-ラーニング系でよくある動画視聴コンテンツなどで、各教材内の動画コンテンツのどの部分が視聴学習されているか、など細かな視聴実績を把握することが可能になるようです。つまり、動画を開いてもすぐに終了させてしまうとバレてしまう。 また、APIで情報の入出力ができるようになるので、業務系システムなど外部システム間の連携が容易にできるというメリットもあります。 その他教育系API　 Google Classroom API Experience APIに準拠しているのか不明ですが、GoogleもClassroomという教育系プラットフォームを提供しています。 まだ評価フェーズですが、APIもデベロッパに公開されています。 教育分野においては、コンテンツの互換性が特に重要であることから、インタフェースの仕様については早くから業界標準が存在していました。 そしてExperience APIが定義され、各個人の学習活動履歴がビックデータとして様々な用途に活用されはじめています。 教育分野は新規参入が難しいイメージがありますが、標準化されたAPIを上手く活用することで新たなビジネスチャンスが期待できる分野なのかもしれません。

APIは作って終わりではなく、徐々に機能追加したり問題があればフィックスをします。それを繰り返す内に起きるのがバージョンアップ問題です。今回はAPIのバージョンアップに絡んだ問題と、その解決策を紹介します。 URL設計 将来のバージョンアップを予期したURL設計にしておくのは大事です。よくあるのは /v1/からURLをはじめるパターンです。これを忘れていると、URLの中に無理矢理入れることになります（/users/ と /users_2/ といった具合に）。 いつをもってバージョンを変えるか悩む これが最も良くある問題ではないかと思います。ちょっとした機能追加でバージョンを上げてしまうと、今後繰り返されるちょっとした修正のたびにバージョンが上がってしまって管理しきれなくなります。かといっていつまでもバージョンアップしないといつまで経ってもv1のままで、何のためにバージョン番号をつけたのか分からなくなってしまうでしょう。 結局のところポリシー次第なのですが、注意点としてはバージョンが変わるとこれまでの既存のAPI全体を作り変える必要があるということです。少なくともコピーすることはできますが、インタフェース設計が変わっていたりすると全体のバランスが崩れてしまいます。 コストがかかる ということはAPIのバージョンが変わると、全面的に作り変える必要が出てくるのです。そのためバージョン1はSOAP、バージョン2はRESTfulなど技術的なパラダイムシフトが起こった、またはアーキテクチャが変わったタイミングでバージョンアップするのが良いかも知れません。 後方互換性を維持するべきか 利用者のことを考えると後方互換性は維持されているのが良いでしょう。サポートとしても、ある機能が使えないときに、それがバージョン1に起因するものなのか、違うのかに判断が困るかも知れません。 ただし後方互換性の維持はモダンな実装の足かせになったり、開発やテストコストの増加につながります。さらに利用しているライブラリをバージョンアップしたタイミングで古いバージョンの動作が変わったりする可能性があります。そのため、できればサーバ自体を分け、過去のAPIについてはノータッチにするというのが安心かも知れません。 古いAPIをいつまでサポートすべきか API連携のシステムは一旦開発するとそのまま放置されるのが一般的です。そのため古いAPIが使えなくなるといったアナウンスをすると、補修が発生します。しかし数年前のシステムを完全に把握しているというのは稀でしょう。 そのため新しいAPIリリース後、1年くらいの猶予は必要だと思われます。しかし多くのケースではうまく乗り換えできず、そのままずるずると古いAPIのまま続いてしまっています。特にB to Bで提供されているAPIではその傾向が強くあります。あらかじめ契約時にその旨（APIのバージョンアップがあること。古いAPIについては段階的に廃止されていくなど）を追加しておくのが良いでしょう。 あらかじめAPIを利用するライブラリを提供しておき、直接APIを触らないようにしておきましょう。そうすることでライブラリのバージョンを変えれば既存のシステムには手を加えずに新バージョンに対応できるようになります。 オープンソースではメジャーバージョンアップしたタイミングで過去の資産をすべて切り捨てることもありますが、多くの場合は継続して利用されます。それを参考にして考えると、バージョン2にアクセスしても既存の機能はそのまま使える方が安全かも知れません。その中で技術的負債になってしまっている機能については推奨せずであったり、期日をもって閉鎖とするのが良いのではないでしょうか。