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にアクセスしても既存の機能はそのまま使える方が安全かも知れません。その中で技術的負債になってしまっている機能については推奨せずであったり、期日をもって閉鎖とするのが良いのではないでしょうか。

認証を行うAPIとしてはOpenIDが有名なのですが、認証だけであるためにメールアドレスの取得であったり、その後のシステム連携に繋げられないといった不満があります。そこで認証と委譲を行うOAuth（特に1.0の問題点を解決したOAuth2）を使うのが一般的になっています。 そこで今回は既存のシステムはもちろん、今後作られるシステムでも手軽にOAuth2の機能が追加できるライブラリを紹介します。 PHP bshaffer/oauth2-server-php : 特に依存のないOAuth2サーバです。既存システムと並列して疎結合で立てるのが良さそうです。 thephpleague/oauth2-server : こちらも独立型ですが、CakePHP3やLaravelとの連携も想定されています。 lucadegasperi/oauth2-server-laravel : Laravelフレームワーク用のOAuth2サーバライブラリです。 zfcampus/zf-oauth2 : 名前の通り、Zend Framework用のOAuth2サーバライブラリです。 bshaffer/oauth2-server-bundle : SymfonyアプリケーションにOAuth2サーバ機能を追加します。 Filsh/yii2-oauth2-server : Yii2アプリケーションにOAtuh2サーバ機能を追加します。 sumeko/phalcon-oauth2-server : こちらはPhalcon向けのOAuth2サーバです。 justingreerbbi/wordpress-oauth-server : WordPressプラグインとして動作するOAuth2サーバです。 Ruby assaf/rack-oauth2-server : Rackアプリケーションなので独立して利用できます。 doorkeeper-gem/doorkeeper : RailsアプリケーションにOAuth2サーバ機能を組み込めます。 songkick/oauth2-provider : ごくシンプルなOAuth2サーバで、Sinatraなどで使うこともできます。 Python joestump/python-oauth2 : Python 2.6/2.7/3.3/3.4に対応しています。多くのフレームワークと組み合わせて利用できます。 hiidef/oauth2app : Djangoアプリケーションの中で使えるOAuth2サーバです。 Node.js thomseddon/node-oauth2-server : Expressと組み合わせて使えるNode.js用のOAuth2サーバです。 ammmir/node-oauth2-provider : こちらもExpressと組み合わせて使うOAuth2サーバです。 .NET IdentityServer/IdentityServer3 : OAuth2だけでなく、OpenIDにも対応したサーバです。 Go RichardKnop/go-oauth2-server : GoとPostgreSQLによるOAuth2サーバです。 Java tuxdna/play-oauth2-server : Play! 2.0 framework用のOAuth2サーバです。 OAuth2サーバを立てることで、APIとしてぐっと使いやすくなります。企業向けとなるとユーザ管理の構造化なども求められるかも知れませんが、基本的にはこれらを拡張していく形で実装できるでしょう。 API構築の際にお試しください。

APIを作る際にはシステムを構築する必要があります。実際、使えるシステムになるか未検証であったり、機能面の過不足が不明確な段階においてあまり作り込むのは避けたいところです。 そこで手元にある既存のリソースを手軽にAPI化してくれるソフトウェアを使ってみましょう。そうすることでモックアップの作成を高速化し、早期に検証が可能になります。 davbre/mira MiraはRuby on Railsを使ったシステムであり、CSVファイルをWeb API化します。元データが静的ファイルなので、GETのみのインタフェースで提供されます。 外部システムとの連携において、CSVファイルをダウンロードした後に他のシステムにはAPI経由でデータを渡すと言ったような使い方もできそうです。 thestorefront/FastAPI FastAPIもRuby製のライブラリで、PostgreSQLをAPI化するのに必要な機能を提供しています。公開するカラムなどを定義しておくだけで、JSON化できます。 jonahoffline/csv2api CSV2APIはRuby製ライブラリで、CSVファイルをJSONまたはXML API化します。CSVファイルごとにパスが切られるので複数ファイルを扱うことができます。一覧表示のWeb表示もサポートしています。 julzhk/simple_api Python製のライブラリでCSVファイルをAPIにします。Google App Engine上で動かす前提となっています。データを検索したり、返却するカラムを指定することが可能です。 acarl/pg-restify PostgreSQLをAPI化します。多少の設定は必要ですが、HTTP経由でデータの取得はもちろん、追加や更新、削除にも対応します。 waldoj/instant-api JSONファイルを読み込んでRESTfulなインタフェースを提供します。実データのJSONファイルでは検索したり、1件だけのデータを取得するような細かな操作はできませんので、よりプログラマブルな使い方が可能になるでしょう。 先日、 Data簡単API化サービス というサービスがリリースされるなど、既存のレガシーな資産をAPIとして活かしたいというニーズは一定数ありそうです。自社データを振り返っても多くの資産が眠っているのではないでしょうか。 そうしたデータはファイルのままではシステム連携しづらいですが、API化することで新しい可能性が見えてくることでしょう。ぜひ活用してください！

去る12月3日、渋谷の21cafeにて Enterprise APIs Hack-Night #2 が開催されました 。今回はそのレポート記事になります。 Enterprise APIs Hack-Night #2 - connpass Office 365 を中核としたこれからの API 戦略 登壇者：日本マイクロソフト株式会社 テクニカル エバンジェリスト 松崎 剛さん Microsoftでは多くのWebサービスを提供していますが、今回はその中でもOffice 365に関する話になります。Office 365ではExtensibility、Remote API Accessがありますが、今回はRemote API Accessについてしょうかいします。技術的にはOAuth2とRESTfulを使っている。 大事なキーワードはOpenness。JavaScriptがあればVisual Studioを使わなくても開発できます。言語にも依存しないので、.NET以外の言語でも開発できます。 もう一つの戦略はクロスデバイス。最近はApple、Androidを優先して開発しているくらいです。昔はWindowsを優先していましたが、iOSやAndroidの上でも自分たちの製品を使ってほしいと考えています。 今後のOffice 365 APIがどうなっていくかについて、まず現状から説明します。 OneDrive SharePoint Exchange Active Directory これらはすべてRESTfulなAPIが用意されています。Azure ActiveDirectoryがすべての認証を司っています。ここだけ取り出して使うことも可能です。ビジネス向けとして、管理者がOKを出したら従業員の方は、わざわざ一つ一つの機能に許可を出さなくてもOAuth認証だけで機能を使えるようにしています。 そして今後についてですが、1週間前に発表したのがUnified - Microsoft Graphです。これまで各APIはエンドポイントがばらばらで、権限も個別に分かれていました。ファイルを上長にメールするなどといったら、各APIにアクセスしないといけない状態で、そのファイルのある場所によって各APIの許可をもらう必要があります。 ユーザが選択したファイルのプレビューを出といった操作をしようとした場合、Exchange、SharePoint、OneDriveの各パーミションを取っておかないといけませんでした。Graphはエンドポイントを一つにし、横の製品間の横断をできるようにします。 Unifiedにはもう一つの側面があります。ビジネスとコンシューマ用APIの統合です。例えばMSにはOneDriveが2つあります。一つは単なるOneDriveで、もう一つはOneDrive for Businessです。同様にSkypeもあります。 今後、すべてAPIのエンドポイントを統一（graph.microsoft.com）していきます。ただし、これはコンシューマとビジネスが一緒になるという意味ではありません。for Businessは今後も残っていきます。APIのエンドポイントを一つにしていくだけです。アプリを一つを作っておくと、もう一つ（ビジネス）にも対応できるようになります。 さらにソケット型のサードパーティ統合が行われます。例えばOffice 365のアプリランチャーの画面に認証したアプリが出るようになります。そしてアプリから簡単に機械学習などのAzureの機能が使えるようになります。その結果、あなたの組織はどれだけ会議をしたかなどをビジュアル化することができたり、セールスフォースなどからデータを出せるようになるのです。 最後にSkype Developer Platform。今はSkypeのオンプレ版しかありません。今後REST APIを出します。音声通話、ビデオ通話に関するAPIを含まれます。JavaScript SDKを出すので簡単に使えるようになるでしょう。 トレタ × Yahoo! JapanのAPIによる提携の話 登壇者：増井 雄一郎 さん Yahooが先日リリースした空席レーダーはトレタのデータを使っています。今から歩いて5分のところにある30人入れる店を探せるようなアプリです。 トレタCEOの中村は元々レストランを経営しており、実際に予約台帳を手書きでやっていました。この予約台帳はレストランの生命線であり、これをデジタル化しようとしているのがトレタになります。 提携の話が出たきっかけは、CEOがたまたまYahooの人と話をしたところからです。Yahooも元々Yahoo予約をやっていたのだけれど視点が違うという認識でした。これまでの問題は、予約サイトから予約があると、紙の台帳に反映して、各予約サイトにも反映するという大きな作業があった。そのため、飲食店側が面倒で使うのを嫌がりました。トレタは予約台帳システムなので、受け口は電話でもAPI経由でもOKというのが大きなポイントです。 そしてYahooとトレタで予約を軸に毎週ペースで会議を重ねて、APIのフォーマットを議論していきました。お互いサービスの初期設計の段階から提携できる形に設計を行っていたので話はスムーズでした。例えばトレタは予約は埋まる視点、Yahooは予約が空いているところという視点で、側面がまったく異なるのです。 今の時代、すべて自分たちでやるというのは無理があります。トレタではレジの会社のAPIとつなごうと考えています。そのためには外部連携することを前提とする必要があります。また、先にAPIの実装が終わっているというのがポイントです。大手と同時にやると力関係が働くので注意が必要です。 さらに本体のコアバリュー以外はAPIとしておく必要があります。また、オープンスタンダードを採用するのもポイントです。他社では独自の仕組みを無理押ししてくると聞きますが、トレタではOAuth2を使っている。標準技術を使っているので繋ぎこみの話がとても早く済みます。 最後に、大手との提携になるとPマークの取得、セキュリティ監査が必須になります。このコストは意外と大きいので、セキュリティチェックすることを前提に、チェック表などを作っておけば良かったと今ではかんじています。 提携先の対応速度は優先度次第です。トレタも今は4000店舗を越えて話がしやすくなっています。リリースしたばかりだと優先度が上がらないので、実績をあげるのが大事です。また、トレタは飲食店の代弁ができるといった立ち位置だったので相手も話を聞いてくれました。今後、スタートアップは大手と組んでいかないといけないと感じています。そんな時、大手に旨味をとられるのではないか、潰されるのではないかと心配してもしかたがありません。大手はリソースがあるので、やろうと思ったら提携せずともできてしまいます。なので自分たちの持ち味をいかさないといけなければならないのです。 「データの力を、まちの力に」〜UDC2015の取り組みとオープンデータ・プラットフォームDKANの活用〜 登壇者：東京大学空間情報科学研究センター（CSIS） 瀬戸 寿一 さん 登壇者：ANNAI 太田垣 恭子 さん 私たちはUrban Data Challenge 2015というプロジェクトを行っています。これは1年間を通して地域課題を解決していくプロジェクトです。地域課題というのは短い期間で結果を出すのは難しいと感じています。例えば札幌の保育園マップをベースとして、同様の動きが東京などに広がっています。 私たちは全国20拠点を設けていて、通年でワークショップで行っています。金沢では毎月ワークショップをやっているくらい活発です。また、社会性ある活動とあって、データパートナーが多いです。国立国会図書館、NAVITIME、オープンガバメント推進委員会などです。 オープンデータについては2014年は2500件でしたが、2015年は10457件と4倍以上になっています。ただし、日本のオープンデータは自治体のサイトに埋め込まれているため、手作業で収集しなければなりませんでした。中にはWeb APIでデータをオープンにしている自治体もゼロではありません。流山市、会津若松市はAPIを提供中です。 このオープンデータを支える仕組みとして知っておいて欲しいのがオープンデータポータルである、そのオープンソース実装がdkanです。システムはDrupalを使っています。DrupalはWebアプリケーションプラットフォームとして知られていて、有名なところではホワイトハウスがあります。政府自治体で24%のシェアを誇っており、オーストラリア政府はすべてDrupalにしようとしているくらい認知度があります。 そしてDrupalはAPI連携に強いCMSであり、REST対応にも対応しています。例えば以下のようなプラットフォームと連携できます。 他のDrupalサイト Android iPhone その他 オープンデータとは誰でも自由に使えるデータ置き場のことです。再利用、再配布も許可されています。そのため、使いやすいことが大事です。外部連携やAPIで取得できたり、各データのURIがあったりといった具合です。ただ、自治体の担当者レベルではCSV公開ですら大変なのが実状です。そんなレベルではデータ検索がしたいニーズはあるのですが、作るのは大変だったりします。 そういった機能をパッケージングしたのがdkanです。Drupal拡張なのでモジュールも利用できます。ECも大丈夫です。似たようなものにCKANもあり（Python）、dkanはCKANとのAPI互換となっています。他にも組織による権限分配に対応していて、自治体のような組織でもワークフローが構築できます。データはSolrを使って検索できます。 ロシア政府データポータルもdkanでできています。表形式で出したりグラフ化、地図化できます。データは一般公開なのか、ユーザ登録必須とするかなど自由に設計できます。 品質APIのご紹介とniconicoでのトライアル事例 登壇者：NTTネットワーク基盤技術研究所 木村 拓人 さん QoEとはユーザ体験の品質のことで、今回は品質APIシステムがどういったものであるか紹介します。仕組みとしては次のようになります。 ユーザから視聴要求がくる 基地局、IPアドレスなどを受け取る 見たい動画に対して幾つかのレートを持っているので、品質APIに問い合わせる 品質APIは最適な動画の品質を返す ネットワーク品質に応じた配信を行うことで、再生停止発生率を著しく低減されられました。また通信データ量を20%下げることにも成功しました。 ユーザの視聴環境、動画配信条件を入力として、最適な配信条件を返す仕組みとなっています。 応用として、 通信前にAPIを叩くことで、通信状況が悪いためしばらくお待ちくださいといった案内が出せる 通信品質マップ などが考えられます。 第1回に比べて企業色を強く打ち出したイベントになっているかと思います。参加者の方の満足度も非常に高く、登壇の後の懇親会も大変盛り上がっていました。 次回は2月10日を予定しています。ぜひご参加ください！

APIを提供する多くのサービスにおいてステータスページを提供しています（ AWS Service Health Dashboard 、 GitHub System Status 、 Apps Status Dashboard など）。特に企業向けにAPIを提供する際にはSLAが必要になりますので、外部から見られるステータスページの存在は大事です。 今回はそんなAPIのステータスチェックの仕組みを作る上での注意点をあげていきます。 1. DB操作を含めること APIサーバに単にアクセスしてレスポンスを受け取るだけであれば、それはAPIというよりもHTTPサーバのステータスレベルのチェックになります。これでは殆ど意味がありません。 確実にDB操作を伴う操作を行うようにしましょう。それによりアプリケーションサーバ、DBサーバのステータスがチェックできます。なおファイルを保存したりする場合はその部分も動作チェックを行う必要があります。 2. 正しいエラー操作を行う 正常系だけのテストでは片手落ちです。400系、500系を含めた正しいエラーコードが返ってくるかどうかもきちんと確認しておきましょう。時々エラーステータスコードを変更したりすることがありますが、元々のエラーステータスを期待しているクライアントもあります（正常系ですが、200が201になるなど）。 APIのステータスチェックはブラックボックステストになりますので、正常系はもちろんのこと、エラー系についても網羅的にテストしておく必要があるでしょう。 3. データをクリーニングする ステータスチェックはテストではありませんので、一般的に本番サーバ上で行われます。そのためステータスをチェックする際にデータを追加している場合は、それを元に戻してあげる必要があります。 登録したデータに対して削除処理を行うことで元の状態に戻るようにしておく必要があります。特にリアルタイムバッチ処理であったり、ファイルの保存が伴う場合にもきちんとデータが削除されるようにしましょう。その点においてRESTful APIであればDELETEメソッド時の処理として保証されるでしょう。 4. 認証を行う DBを操作する場合と同様にAPIのステータスをチェックする際には認証を行うようにしましょう。できれば新規ユーザの作成からユーザアカウントの削除まで一貫してチェックできるのが良いでしょう。 認証の状態によってエラーが発生するというのはよくありがちです。特に本番環境のデータは予定していたものと異なる場合も多く、その結果としてAPIがエラーを起こすというのはよくあります。 5. レスポンスを測定する ステータスは生死確認だけではありません。レスポンスについても測定し、閾値を越えるようであればアラートを出すようにしましょう。特にデータ量の増加に伴うレスポンス低下は最初には分からないエラー要因になりますので注意が必要です。 APIの場合、外部システムから定期的に多くのリクエストが発生します。一度待ちが発生すると、雪だるま式に積み重なって処理しきれなくなる可能性があります。トークンごとのアクセス制御も必要ですが、システムのレスポンスが適切にできているか（遅延が発生していないか）は常に注視しましょう。 6. 海外からのステータスもチェックする インターネットはグローバルなサービスであり、国内限定のAPIでもない限りは海外からの利用においてもステータスのチェックが必要です。時々、特定の外国からアクセスできないといった問題が発生することがあります。もちろん多くの場合は諸外国側のネットワーク問題になります。 ステータスチェックを同じサーバ、ネットワーク内で行っても意味がないのと同様、なるべく離れたサーバから監視する必要があります。その際には日本、US、EUなど複数箇所からモニタリングできるようにしましょう。 7. APIが外部サービスにつながる部分も確実に、かつ慎重に APIゲートウェイの場合、APIがさらに外部のAPIに接続して出力を加工していることがあります。そうした場合、自社のサーバは問題がなくとも、外部サーバのエラーによってAPIに問題が生じることがあります。 外部サービスへの過度の負荷は避けるべきですが、APIのステータスチェックを行う際には外部サービスも含めて確実に行っておきましょう。また、外部サービスがエラーになっても利用者に不具合が発生しないよう、あらかじめエラーステータスコードを設けておきましょう。 しっかりと構築されたシステムにおいてもエラーは発生するものです。Webブラウザからのアクセスであれば人が見た目で判断して復旧までアクセスを控えることができます。しかし自動化されたシステムにおいてはそういった機構が備わっていないことも多々あるようです。 予想外のエラーは利用者のシステムに思いもしなかったエラーを発生させる可能性があります。そうならないためにも日々の運用状況を適切に可視化するようにしましょう。

最近になってFinTechと言われるキーワードが聞かれるようになってきました。Finance + Techの造語で、特に銀行/証券系などの金融サービスとインターネットテクノロジーを組み合わせた新しいサービスを指し示しています。 FinTech自体は概念となっており、その特徴としては以下のように挙げられます。 1. オープンではなくクローズドなAPI公開 みずほ銀行とLINEが提携して、 LINE上で残高照会ができるサービス を開始していたり、 住信SBIネット銀行とマネーフォワードが提携して家計簿に反映 するといった事例が見られるようになっています。要点としては、これらは一般公開されたオープンなAPIではなく、提携企業にのみ公開されるクローズドなAPIであるということです。 FinTechはお金が絡むとあって、一つのミスが金融企業の根幹を崩しかねない危険性をはらんでいます。それだけに多くの企業がAPI公開に及び腰だったのですが、周辺サービスが拡充してきたのに合わせて特定企業向けにAPI公開する流れになっていると言えます。 2. オンライン決済サービスが牽引 FinTechというワードは後付けで、元々PayPalなどを筆頭に決済・送金サービスの多くはAPI公開をしています。日本でもここ数年で SPIKE（スパイク） や WebPay 、 PAY.JP といった新しい決済サービスが誕生しています。 また、数年前に話題になったBitCoin系の仮想通貨サービスも様々な問題は抱えつつも規模を拡大しており、ブロックチェーンサービスとして成長しています。特に マイクロソフトではEthereum Blockchain as a Service（EBaaS）としてクラウドのブロックチェーン開発環境の提供を開始 しています。 3. 世界におけるトレンド まだまだ技術革新が考えられるとは言え、成熟している決済サービスの他に世界で注目を集めている分野は主に3つ考えられます。一つは銀行系である預金、資産運用系です。もう一つは資金調達や融資に関係するもので、VCなどの巨額のものではなく、個人や中小企業を対象としたマイクロファイナンス系になります。 最後は企業向けのサービスです。現状、FinTech系の多くは消費者向けに提供されるものが多くなっています。そしてそのデータは自社サービスの機能拡充として提供されるものです。対して企業向けの場合は新しい収益源になりえるものが期待されるでしょう。APIによる自動連携をもとに新しい事業が生み出せるかどうかが市場の未来を握っているのではないでしょうか。 4. 自社だけで完結しないのがFinTech 金融×テクノロジーというだけではWebサービス化して終わりのように見えますが、FinTechの特徴としてAPIに注目しなければならないでしょう。つまり他社との連携を視野に入れる必要があります。そのためプレイヤーとしては、基盤になるサービスを提供する企業と、それらを使って顧客やユーザ向けに情報提供する企業とに分かれています。 前者はどちらかというと銀行や証券外車と言った長い歴史をもった企業が、後者はマネーフォワードやfreeeといった新興企業が多いようです。いずれにせよ、新しいユーザ層である若い世代や新しいツールを使いこなす人たちを囲い込んだ新興企業の顧客層を旧来の金融系企業の基盤と組み合わせることで新しい魅力が生まれる点がFinTechの魅力と言えます。 逆に垂直統合的に自社だけでやろうとするのは幅広いユーザ層の取り込みという点においてお勧めされません。銀行一社が自分たちの顧客向けだけにサービスを作ったとしても、現在は複数の預金先をもっている人が殆どでしょう。そうした他の銀行まで扱える可能性がないサービスをあえて使おうとする人は多くないと考えられます。 実際のところ、一般企業としてFinTechをどう捉えるべきなのでしょうか。幾つか考えられます。 現在FinTech関連は出資を受けやすいということもあり、FinTech関連の事業を興す API連携を使って自社の経理周りの業務を自動化する 中小企業融資など、FinTechサービスを利用する 世界をソフトウェアが飲み込むというのは数年前に出たフレーズですが、実際金融系においても通貨や証券の仮想化・デジタル化を通じてソフトウェア化が進んでいると言えます。現実世界で感じている課題があれば、それをソフトウェア化することで解決できる可能性があるでしょう。

初めまして! APIゲートウェイのサービス企画をやっているnakajimaです。 今回が、開発者ブログ初投稿です。 本記事は、Enterprise APIs Advent Calendar 2015でも公開しております! Enterprise APIs Advent Calendar 2015 さまざまな企業が自社のAPI利用者向けサイトを用意しておりますが、いざ使ってみようと思っても、初心者には難しいなんてことがあると思います。 そこで今回は、いろいろな企業が公開しているAPIの使い方をまとめて勉強できる便利なサイトを紹介します。 （ほぼ日本語未対応だったりしますが。。。大丈夫です! そんなに難しいことは言ってないです。） それが、 codecademy です。 codecademy JavaやPythonなどのプログミング言語、Ruby on Rails や AngularJSなどWeb開発者向けの技術スキルをオンラインで学習できます。 codecademy 学習コンテンツ一覧 また学習用に環境を構築する必要がなく、コード作成および動作確認は、ブラウザ内で完結するので、勉強を始めるまでに余計いな手間がかかりません。 しかも基本無料です。 既にご存知の方は、プログラミング言語を勉強するサイトと認識されているかもしれません。 しかし、一番最後にさりげなく『Learn APIs』という項目があります。（2015.12現在） boxやgithubなど、全14種類のAPIが学べます。（こちらも2015.12現在） 私自身は、Apigee API に入門してみました。 APIを学ぶまでの流れを以下で紹介します。 1.アカウント作成 まずは何はともあれ、アカウントの作成からです。 アカウントを作らなくても、利用できますが、自分の進捗状況が管理できるので大変便利です。 またGoogle IDやFacebook IDでもログインできます。 アカウント作成の手順は、たったの2つです。 まずは、Top画面の[Email]と[Password]を入力して、[SING UP]ボタンを押します。 次に、[Username]を入力して、[I'm not a robot]チェックボックスにチェックを入れて、[GET STARTED!]ボタンを押せば完了です! 2.勉強する API の選択 アカウント作成後、教材一覧ページが表示されます。 ページの一番下まで行くと、[Learn APIs]があるので、こちらをクリックします。 一つ目のApigee社のAPIを選択します。 3.APIの学習 Apigee社の学習メニューは、2つです。 ・javascriptによるAPIのリクエスト方法 ・Apigee社のAPIを利用して自分のアプリケーションのデータをクラウド環境に保存するリクエスト方法 javascript自体が初めてという人には、codecadamyでjavascriptの教材も提供しているので、こちらもオススメです。 codecadamyのjavascript学習ページ 実際に学習するページは以下のような構成になっております。 左側に課題があり、それに対応するコードを中央のエディタの部分に記載し、結果確認ボタンを押します。 結果が、右側の結果確認画面に表示されます。 正解すると次の課題に進めるという感じです。 課題によって、ヒントもあります。 時間があるときに他のAPIも学んでみたいと思います。 みなさんも是非!!

Enterprise APIs Advent Calendar 2015への投稿記事です(第二弾) Enterprise APIs Advent Calendar 2015 エンタープライズなネタということで、DropboxやGoogleDriveなどのオンラインストレージサービスをよりセキュアに利用できる仕掛けを考えてみました。 当然ながら各サービスプロバイダは様々なセキュリティ対策を講じていますが、自己防衛と言いますか、二重、三重に対策を行うことがセキュリティの原則です。 例えばアカウントが漏れてしまった場合、オンラインストレージに保存したファイルが第三者に悪用されてしまう可能性があります。 ファイル自体に暗号化を施してオンラインストレージへアップロードしておけば、仮にアカウントが漏洩したとしても中身を見られるリスクは限りなく低くなりますが、都度ファイルを暗号化してオンラインストレージにアップロードする作業は面倒です。 ということで、以下のファイル操作を自動化して、利便性を落とさずよりセキュアにオンラインストレージを利用する仕掛けを、OneDrive APIとApigeeを使って試してみました。 クライアントからアップロードされたファイル(テキスト)を自動的に暗号化し、オンラインストレージへ送信する オンラインストレージからダウンロードしたファイル(テキスト)を自動的に復号し、クライアントへ返す 下準備 OneDrive API OneDrive APIを利用できるように、 デベロッパサイト よりアプリケーション登録しておきます OneDrive APIのリファレンスも上記デベロッパサイトより確認できます Apigeeへサインアップ Apigee にアカウント作成し(今回は無償アカウントを使っています)、API ManagementからAPI Proxyを作成できるようにしておきます 今回はAPI Proxyを以下のような感じで作成しました。 OneDrive APIは様々なAPIが用意されていますが、今回利用するAPIはアップロードAPIとダウンロードAPIの２つです。 この２つをResourcesに追加しておきます。(パスは同じでGETかPUTかメソッドを使い分けて利用します) ファイル自動暗号化のロジックを作成する 以下の流れでApigee上にAPI Proxyを作成していきます。 ※Apigeeの各ポリシー詳細については Apigee Docs を参照してください。 RequestフローにExtract Variablesポリシーを追加し、OneDrive ファイルアップロードAPIのRequest Payloadを抽出 JavaScriptsで暗号ロジックを作成し、抽出した文字列を暗号化する ファイルの暗号/復号にはJavaScriptsの crypto-js というライブラリを使って実装してみました 暗号化した文字列をRequest Payloadに戻し、OneDrive APIを叩く 以上で終了です。 Apigee上で作成したAPI Proxyは以下のようになりました。 それでは実際に作成したAPIを叩いて、アップロードしたファイルが暗号化されているか確認してみます。 以下、HTTPieというコマンドツールを使ってAPIを叩いてみます。 $ echo 'Enterprise APIs Hack-Night #2' | http -v PUT http://*****.apigee.net/drive/root:/test/message.txt:/content "Authorization: Bearer ******" [Request] PUT /drive/root:/test/message.txt:/content HTTP/1.1 Accept: application/json Accept-Encoding: gzip, deflate Authorization: Bearer ****** Connection: keep-alive Content-Length: 30 Content-Type: application/json Host: *****.apigee.net User-Agent: HTTPie/0.9.2 Enterprise APIs Hack-Night #2 message.txtにEnterprise APIs Hack-Night #2（明日開催する勉強会です！）という文字列を書いて、OneDriveにアップロードしています。 APIの書式、AccessTokenはOneDrive APIを利用しますが、ここで指定するAPIのエンドポイントは、Apigeeで作成したAPI Proxyのエンドポイントになります。 アップロードを実行する中で、API Proxyにて暗号処理が実行され、OneDriveに暗号化ファイルが保存される仕組みです。 それではアップロードしたmessage.txtの中身が暗号化されているか、直接OneDriveにアクセスして確認してみます。 message.txtをダウンロードし開いてみると、 このように"Enterprise APIs Hack-Night #2"という文字列が暗号化されているのがわかります。 これで万が一、アカウントが漏れて第三者にアクセスされても、ファイルの中身が分からないので情報漏洩を防ぐことが可能となります。 ファイル自動復号のロジックを作成する このままではファイルを読み取ることができないので、復号ロジックをAPI Ploxyに追加していきます。 以下の流れでApigee上にAPI Ploxyを作成していきます。 ※OneDriveのファイルダウンロードAPIは、まずダウンロードリクエストを投げて、ファイルをダウンロードするURLを取得し、取得したURL(テンポラリ)に対してGETでファイルを取得する流れになっています。 この一連の流れをAPI Ploxy上に実装していきます。 ResponseフローにExtract Variablesポリシーを追加し、ファイルダウンロードURLのパスを抽出 Service Calloutポリシーを追加し、抽出したURLからファイルをダウンロードする ダウンロードしたファイルから暗号化文字列を抽出する JavaScriptsで復号ロジックを作成し、抽出した暗号化文字列を復号する 復号した文字列をResponse Payloadに戻し、クライアントへ返す 以上で終了です。 Apigee上で作成したAPI Proxyは以下のようになりました。 それでは実際に作成したAPIを叩いて、ダウンロードしたファイルが復号されているか確認してみます。 $ http -v GET http://*****.apigee.net/drive/root:/test/message.txt:/content "Authorization: Bearer *****" [Request] GET /drive/root:/test/message.txt:/content HTTP/1.1 Accept: */* Accept-Encoding: gzip, deflate Authorization: Bearer ***** Connection: keep-alive Host: *****.apigee.net User-Agent: HTTPie/0.9.2 [Response] HTTP/1.1 200 OK Accept-Ranges: bytes Cache-Control: public Content-Disposition: attachment; filename="message.txt" Content-Encoding: gzip Content-Length: 84 Content-Location: https://****** Content-Type: text/plain Date: Tue, 01 Dec 2015 04:15:16 GMT Expires: Mon, 29 Feb 2016 04:15:17 GMT Last-Modified: Tue, 01 Dec 2015 03:54:20 GMT P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo" Server: Microsoft-IIS/8.5 Strict-Transport-Security: max-age=31536000; includeSubDomains X-AsmVersion: UNKNOWN; 19.32.0.0 X-Content-Type-Options: nosniff X-MSNSERVER: DM2304____PAP035 X-PreAuthInfo: rv;poba; X-SqlDataOrigin: S X-StreamOrigin: X Enterprise APIs Hack-Night #2 正常に文字列が復号されていることを確認できました。 このように、APIを活用すればセキュリティを強化してオンラインストレージを利用する仕組みも簡単に作れます。 今回、アプリケーションの開発まではやっていませんが、APIを叩くだけの簡単な実装でWebやモバイルアプリを開発できるかと思います。 これもAPI活用のメリットの一つですね。 また、暗号処理は固定の暗号鍵を使っていますが、外部のセキュリティサービスなどと組み合わせて利用することにより、さらにセキュリティレベルを上げてオンラインストレージを使うこともできると思います。 ほかにも組み合わせることで面白いことができそうなサービスがあればチャレンジしてみたいと思います。

Enterprise APIs Advent Calendar 2015の一回目ということでどのネタにしようかいろいろ考えましたが、以前紹介した REST API用テストフレームワークまとめ の apickli/apickli 検証ネタを書きます。 Enterprise APIs Advent Calendar 2015 apickli/apickli Cucumber フレームワークという、 Behaviour-Driven Development (BDD) を実現するフレームワークです。システムテストにおいて受け入れテストに向いている自動化フレームワークです。 apickliは、Cucumberフレームワークをnode.jsで実装した cucumber.js を活用、自然言語シナリオをもとにREST APIのリクエストに対して期待値のレスポンスをOK/NGをテスト可能。 Given(前提)、When(もし)、Then(ならば)、and(かつ)、but(しかし)を組み合わせでテストシナリオを書いてきます。 事前準備 適当な環境(linux,macなど)でGitHubから環境をとってきます。 node.jsは nvmなどで稼働できるようにしておく とよいです。 では手順にしたがって準備していきます。 node.js install npm install -g cucumber apickliをダウンロード git clone https://github.com/apickli/apickli.git サンプルプロジェクトの確認 cd apickli/example-project/test tree . └── features ├── fixtures │   └── requestBody.xml ├── httpbin.feature └── step_definitions ├── apickli-gherkin.js -> ../../../node_modules/apickli/apickli-gherkin.js └── httpbin.js という構成になっていると思います。 package.json編集 cd .. cat package.json { "name": "httpbin-test", "version": "1.0.0", "description": "Integration testing for myapi with httpbin.org", "dependencies": { "apickli": "latest" } } 上記のように編集します。nameのところは、 httpbin を活用したテストなのでこれでよいです。 httpbinとは、REST APIで取り急ぎ、サンプルリクエストに対し、レスポンスを提供してくれる便利な無料APIになっています。 依存関係のモジュールをインストール npm install package.jsonの置いてるところで、本コマンドを実施してください。 これで依存関係のモジュールがインストールされます。 サンプルシナリオの宛先確認 cd apickli/example-project/test/features/step_definitions vi httpbin.js //中略 this.apickli = new apickli.Apickli('http', 'httpbin.org'); このファイルにテストしたいAPIの宛先を書きます。 まずは、デフォルトのままでよいです。 サンプルシナリオの実行 これでfeatures/httpbin.featureに書かれているシナリオに従って実行されていきます。 とりあえず実行してみましょう。 cd apickli/example-project/test cucumber-js features/httpbin.feature テストの標準出力結果一部 Feature: Httpbin.org exposes various resources for HTTP request testing As Httpbin client I want to verify that all API resources are working as they should Scenario: Setting headers in GET request # features/httpbin.feature:5 Given I set User-Agent header to apickli # ../node_modules/apickli/apickli-gherkin.js:6 When I GET /get # ../node_modules/apickli/apickli-gherkin.js:31 Then response body path $.headers.User-Agent should be apickli # ../node_modules/apickli/apickli-gherkin.js:153 Scenario: Setting body payload in POST request # features/httpbin.feature:10 Given I set body to {"key":"hello-world"} # ../node_modules/apickli/apickli-gherkin.js:11 When I POST to /post # ../node_modules/apickli/apickli-gherkin.js:41 Then response body should contain hello-world # ../node_modules/apickli/apickli-gherkin.js:137 (中略) Failing scenarios: features/httpbin.feature:25 # Scenario: Setting body payload from file 24 scenarios (1 failed, 1 ambiguous, 22 passed) 70 steps (1 failed, 2 ambiguous, 2 skipped, 65 passed) 0m13.164s The following steps have multiple matching definitions: "I subtract remaining2 from remaining1" matches: /^I subtract (.*) from (.*)$/ # features/step_definitions/apigw.js:16 /^I subtract (.*) from (.*)$/ # features/step_definitions/httpbin.js:16 "result should be 1" matches: /^result should be (\d+)$/ # features/step_definitions/apigw.js:24 /^result should be (\d+)$/ # features/step_definitions/httpbin.js:24 という感じで、出力されます。一部エラーが出てますね。 テストのオプション Usage: cucumber-js [options] [<DIR|FILE[:LINE]>...] Options: -h, --help output usage information -v, --version output the version number -b, --backtrace show full backtrace for errors --compiler <EXTENSION:MODULE> require files with the given EXTENSION after requiring MODULE (repeatable) -d, --dry-run invoke formatters without executing steps --fail-fast abort the run on first failure -f, --format <TYPE[:PATH]> specify the output format, optionally supply PATH to redirect formatter output (repeatable) --no-colors disable colors in formatter output --no-snippets hide step definition snippets for pending steps --no-source hide source uris -p, --profile <NAME> specify the profile to use (repeatable) -r, --require <FILE|DIR> require files before executing features (repeatable) --snippet-syntax <FILE> specify a custom snippet syntax -S, --strict fail if there are any undefined or pending steps -t, --tags <EXPRESSION> only execute the features or scenarios with tags matching the expression (repeatable) For more details please visit https://github.com/cucumber/cucumber-js#cli の感じで、タグ指定なんかを使うとシナリオテストをブロックごとにタグ分けしておくとそこの部分だけテストができます。 cucumber-js features/httpbin.feature --tags @token Feature: Httpbin.org exposes various resources for HTTP request testing As Httpbin client I want to verify that all API resources are working as they should @token Scenario: Access token retrieval from response body (authorization code grant, password, client credentials) # features/httpbin.feature:81 Given I set Token header to token123 # ../node_modules/apickli/apickli-gherkin.js:6 When I GET /get # ../node_modules/apickli/apickli-gherkin.js:31 Then I store the value of body path $.headers.Token as access token # ../node_modules/apickli/apickli-gherkin.js:169 @token Scenario: Using access token # features/httpbin.feature:87 Given I set bearer token # ../node_modules/apickli/apickli-gherkin.js:174 When I GET /get # ../node_modules/apickli/apickli-gherkin.js:31 Then response body path $.headers.Authorization should be Bearer token123 # ../node_modules/apickli/apickli-gherkin.js:153 2 scenarios (2 passed) 6 steps (6 passed) 0m01.104s こんな感じです。 シナリオの記述の仕方は、 Cucumberのfeatureファイルのプラクティス にもありますが、 given (code) | "前提" when (code) | "もし" then (code) | "ならば" and (code) | "かつ" | but (code) | "しかし", "但し", "ただし" をうまく組み合わせすることで、様々な受け入れテストのパターン分岐のシナリオを記述することができると思います。 apickliで最初から準備されてる便利なところ 基本、test/featuresの*.featureファイルに自然言語にてシナリオを記述し、そのシナリオに従ったコードを、test/features/step_definitions配下にモジュールを記述していきます。 test/features/step_definitions/apickli-gherkin.jsがライブラリ的に最初から用意されているので、 I set body to {"key":"hello-world"} I POST to /post response body should be valid json response header boo should not exist response body should contain WonderWidgets などのようなリクエスト、レスポンスの中身チェックが簡単にできるところが、非常にテストに有益と思います。 これで、 Jenkins などのCIツールと組み合わせすれば、APIサーバモジュールリリースに合わせて、シナリオ自動テストができますね。 別途、Jenkins+Docker+cucumber.jsでやってみたいと思います。 REST APIの受け入れテストは、まだまだこれからベストプラクティスが出てくるかと思いますが、他にも良いフレームワークがあれば、実際に使って紹介していきたいと思います。

JSON Schemaを手作業で作っていくというのは現実的ではありません。システムで用いるものとあって、書き方が分かりづらい部分があったり、バリデーションの条件などは記述が面倒です。 そこで使いたいのがJSON Schema生成ソフトウェアやライブラリになります。各プログラミング言語ごとに存在しますので使いやすいものを選んでください。 JSON Schema Generator JSON Schema GeneratorはWebブラウザ上でJSON Schemaの編集ができます。全体の設定に加えて、各項目単位でバリデーションの設定をビジュアル的に実行できるようになっています。 結果は一行のJSON文字列になりますので、そのまま開発で利用できます。 json-schema-generator Node.jsのライブラリで、可読性の高いフォーマットでJSONフォーマットを定義します。それを json-schema-generator コマンドを使って変換することでJSON Schemaにできます。 手作業でValidなJSON Schemaを組み立てるのに比べて大幅に手軽になることでしょう。 perenecabuto/json_schema_generator Pythonのライブラリで、指定したJSONファイルに対してすべての項目の型と入力必須かどうかを定義します。生成されたものをそのまま使うと言うよりも、値の範囲や必須か否かを編集した上で使うのが良さそうです。 Nijikokun/generate-schema Node.jsのライブラリで、上記Pythonライブラリと同じようにJSONファイルを読み込んで型を定義したJSON Schemaを出力します。JSON Schemaだけでなく、Mongoose Schemaにも対応しています。 JSON Schema Generator 拡張機能 Visual Studio 2013 Update 2以降で使えるプラグインになります。JSONファイルを指定し、コンテクストメニューからGenerate JSON Schemaを選択します。 JacksonJsonSchemaGeneration - FasterXML Wiki JavaのJSONライブラリであるJacksonを使ったJSON Schema Generatorです。Javaオブジェクトを指定して、そのプロパティをJSON Schemaに変換します。実際に動いているシステムをJSON Schema化したい時に使えそうです。 JSON Schema Editor Windows用のソフトウェアとして販売されています。ビジュアル的にJSON Schemaが定義でき、バリデーションも細かく指定が可能です。構造はドラッグ&ドロップで変更できるなど使い勝手は良さそうです。 json-schema-generator | RubyGems.org | your community gem host インストールするとjson-schema-generatorというコマンドが使えるようになります。オプションとしてSchemaのバージョンが指定できるようになっています。 solvire/php-json-schema-generator PHPライブラリです。composerを使ってインストールができます。コマンドで使うのではなく、システムに組み込んで用いるようです。 ae real / JSON-Schema-Generator - search.cpan.org Perl向けのライブラリです。ハッシュをベースにしてJSON Schemaを生成する仕組みになっています。 mcuadros/go-jsonschema-generator GoのオブジェクトをJSON Schemaに変換できるライブラリです。すべてのプロパティを定義し、必須条件についても記述されます。バリデーションについては別途記述する必要があります。 JSON Schemaを生成する方法としては各プログラミング言語におけるオブジェクトをJSON Schemaとして出力するものと、ビジュアル的にJSON Schemaを作成していくものの2種類に分けられるようです。 すでにシステムが稼働している中にあっては、ライブラリと組み合わせるものが使いやすそうです。ただし細かなバリデーションは設定しなければなりませんので注意してください。ビジュアルエディタは仕様から考える際に使えるでしょう。

今後、企業間連携においてAPIをベースにするのはごく当たり前になっていきます。その時、提携が決まってからAPIを開発しているのではとても昨今のビジネス環境の変化に追随できないでしょう。 そこで将来を見据えた上で社内データをAPI化する際に注意して欲しいポイントについて挙げていきます。 1. 24時間365日のアクセスを想定する 社内システムは一般的に営業時間中しかアクセスされません。そのため夜中にシステムを停止したり、バックアップなどの高負荷な作業は深夜に行うのが一般的です。しかし社内データを公開するとなると、そのデータへのアクセスは24時間/365日、いつでもどこからでも行われると想定する必要があるでしょう。 そのためデータベースを停止してバックアップするような運用はできず、オンラインでのバックアップや構成変更も行えるようになっていなければなりません。停止する場合はそれを想定した仕組み（適切なエラーコードを返すなど）を行ったり、数週間前から告知するなど運用面も考えなければならないでしょう。 2. 公開範囲を決める 社内データをAPI化＝全データを無制限にアクセスさせるという訳ではありません。その公開範囲をきちんと決める必要があります。ただし、あまり絞りすぎると利用者にとって魅力的なものではなくなりますし、広げすぎると不要な情報漏洩を招く恐れがあります。 やり方として、最初は絞り込んで限定されたパートナーのみに公開し、フィードバックをもらいつつ必要な情報をオープンにしていくという方法があります。API作成側ではすべてのニーズを想定するのは難しく、実際の利用者から意見をもらいつつ進めるのは質実剛健でありお勧めです。 さらに業務システムでは大量のデータを必要としたり、グルーピング（集計）したいというニーズがよく出ますが、これをデータベースまま操作すると高負荷になってしまうことがよくあります。適度に集計結果を別テーブルに移しておいたり、最新データと過去データを分割して管理するといった工夫が必要です。データに触れる人が増え、かつ皆が重たい処理を行うとこれまでにない以上にサーバのレスポンスが落ちることでしょう。 3. 作成/更新/削除できる箇所を決める 公開は情報の発信だけですが、これではAPIの作成およびシステム連携を行う上では片手落ちと言えます。新規データの作成、更新および削除という、いわゆるCRUD操作ができてはじめて意味のあるものになるでしょう。 データの操作を行わせる範囲についてはデータの取得以上に注意が必要です。さらに間違った修正に対応できるように差分を残しておいたり、トランザクションを必要とする更新を望まれることがあります。APIにおいてトランザクションを実装するのはとても困難ですが、バッチ処理的な方法であれば実装しているところもあります。 4. 認証およびログを取る データを誰が参照して、誰が更新したかを記録するのはとても大事なことです。社内の監査システム以上に厳しくデータを記録しておく必要があるでしょう。APIは一気にデータを削除できる可能性もありますので、フィードバックできるようにデータを残しておく必要もあります。 また、不正なアクセスにも対応しなければなりません。アクセス元を記録したり、アクセス方法によっては不正なアクセスであると検知できなければいけないでしょう。そういった認証とは別なアクセス権限についても考えるべきです。 5. 既存ワークフローに悪影響を及ぼさない 社内データはすでに社員によって扱われているデータになります。そうしたデータをオープンにした結果、ワークフローに遅延が生じたり、不具合によって業務が回らなくなってしまうような自体は防がなければなりません。 API化が既存業務にマイナスの影響を与えると、次のAPI化において反対する人が多くなるでしょう。APIの公開に伴ってビジネスの拡大はもちろんのこと、業務コストの低減やスピードアップがはかれるかどうかは大事な指針といえます。 6. セキュリティを重視する 社内データは企業にとっての要といえます。それだけにセキュリティについては重視しなければならず、しすぎということはありません。実際、API公開する中で使われる機能は1つか2つだけかもしれず、残りの殆どの機能は使われない可能性があります。 そうした使われないAPIというのはメンテナンスされず、セキュリティリスクになりやすいものです。頻繁によく使われるものを重視して公開すべきでしょう。 7. すでにある仕組みに則って開発する 例えば認証であればOAuth2であったり、OpenIDといった標準プロトコルがあります。RPC（リモートコールプロシージャ）やREST APIについてもすでに数多くのライブラリが作られており、そうした技術標準に沿っておくことは後々のメンテナンス性、拡張性を考えた上でも利点があります。 企業においては独自指向になりやすい傾向があり、その結果として時代に取り残された使い勝手の悪いAPIが残されていきます。複数の企業とのシステム連携を考えるならば、なるべく業界標準になっている仕組みに合わせた実装を行いましょう。 エンタープライズのAPI活用においては自社基幹システムに入っているデータを公開するのはとても大事なことになります。ただし何も考えずにただ公開すると大きな問題になりますし、かといってリスクばかりを考えて絞り込みすぎるのも問題です。リスクとメリットを鑑みた上で、プラスになるポイントを見極める必要があるでしょう。 ぜひ自社データのオープン化について考えてみてください。

企業システムである以上、品質の担保は大事な要件です。そしてそれを支えるのは十分なテストになります。REST APIは一見するとHTTPアクセスになりますのでテストは何でもできそうですが、やはり専用のライブラリを使う方がコード量も短くて済みます。 apickli/apickli Node.js向けに作られており、Node.jsでよく使われているテストフレームワークCucumber.jsと組み合わせて利用できるフレームワークとなっています。Featureは例えば次のように記述されます。 Feature: Httpbin.org exposes various resources for HTTP request testing As Httpbin client I want to verify that all API resources are working as they should Scenario: Setting headers in GET request Given I set User-Agent header to apickli When I GET /get Then response body path $.headers.User-Agent should be apickli chitamoor/Rester Python向けのREST APIテストフレームワークです。専用のapirunnerというコマンドにテスト用の設定ファイル（JSONまたはYAMLで記述）を渡して実行します。JSONは次のように記述します。 { "testSteps": [ { "name":"Name of TestStep", "apiUrl":"http://example/api/v1/helloworld/print", "asserts":{ "headers":{ "content-type":"application/json; charset=utf-8" }, "payload":{ "message":"Hello World!" } } } ] } jeffbski/bench-rest bench-restはベンチマークを取るのに使うNode.js製のソフトウェアです。例えば次のような結果が得られるようです。 $ bench-rest -n 1000 -c 50 ./examples/simple.js Benchmarking 1000 iteration(s) using up to 50 concurrent connections Using flow from: /Users/barczewskij/projects/bench-rest/examples/simple.js { main: [ { get: 'http://localhost:8000/' } ] } Progress [=======================================] 100% 0.0s conc:49 1341/s errors: 0 stats: { totalElapsed: 894, main: { meter: { mean: 1240.6947890818858, count: 1000, currentRate: 1240.6947890818858, '1MinuteRate': 0, '5MinuteRate': 0, '15MinuteRate': 0 }, histogram: { min: 4, max: 89, sum: 41603, variance: 242.0954864864864, mean: 41.603, stddev: 15.55941793533699, count: 1000, median: 42, p75: 50, p95: 70.94999999999993, p99: 81.99000000000001, p999: 88.99900000000002 } } } vlucas/frisby FrisbyはNode.js用テストフレームワークのJasmineと組み合わせて使います。テストの記述はコードになっていて、若干独自のものになります。 frisby.create('GET user johndoe') .get(URL + '/users/3.json') .expectStatus(200) .expectJSONTypes({ id: Number, username: String, is_admin: Boolean }) .expectJSON({ id: 3, username: 'johndoe', is_admin: false }) : .toss(); cybertk/abao abaoはテストのベースになるフォーマットとして RAML を採用しています。コマンドでRAMLファイルとAPIのエンドポイントを指定して実行します。 abao api.raml http://api.example.com CarlJi/RestfulAPITests Java用のテストフレームワークになります。JUnitなどと組み合わせられるので、JavaシステムのテストとともにAPIのテストができるようになります。 yookoala/restit RESTitはGo言語で書かれたテストフレームワークで、テストコードは独自のものになります。 この他、Webアプリケーションフレームワーク向けにテストが提供されている場合もあります。その場合はモックに対応しているなど、Webアプリケーションフレームワークを使っているからこそ提供される機能もあります。 今回紹介したようなテストフレームワークは、HTTP/HTTPS経由だけの疎結合でのテストを行うのに向いています。外部システム連携する際や、バージョンアップなどに伴う互換性の確認などに使うこともできるでしょう。