認証を行う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経由だけの疎結合でのテストを行うのに向いています。外部システム連携する際や、バージョンアップなどに伴う互換性の確認などに使うこともできるでしょう。

先日、 Open API Initiative の設立が発表されました（via RESTful APIの記述標準化を目指す「Open API Initiative」をマイクロソフト、Google、IBMらが立ち上げ。Swaggerをベースに － Publickey ）。これにより、RESTful APIが各企業間において標準化され、より広まっていくものと考えられます。 そんなRESTful APIを広めていく中で必要な要素になるのがドキュメントです。APIは開発者向けの画面はなく、プログラムからコールして利用します。そのため、分かりやすいドキュメントが必須になります。その標準フォーマットとして取り上げられているのが今回紹介する Swagger です。 Swaggerとは？ Swaggerはドキュメントフォーマットおよびビューワーになります。Swagger自体オープンソースとして公開されており、関連するツールやライブラリもオープンソースとなっています。Swagger向けに書かれたドキュメントはHTMLファイルに変換できます。 項目をドリルダウンすると、HTTPメソッドとパスが一覧表示されます。これにより実装されている機能が一目で分かります。 さらに各機能をクリックすると、処理を行う際に必要なデータが分かります。 処理を行うのにOAuth2が必要な場合にはこの画面から認証へ飛ばすことができます。 そして処理を実際に行って結果を確認できます。Content Typeの指定もできますので、必要に応じてXMLまたはJSONで受け取ることも可能です。 このようにSwaggerは開発者のためのインタラクティブなドキュメントと言えます。ただ読むだけでなく、処理をその場で行って結果を確認できるようになっています。なお、 SwaggerのドキュメントはJSONファイルをベースにして生成 されています。つまりこのドキュメントの元になるJSONファイルさえ用意すれば、サーバサイドの言語に関係なくドキュメントが生成できるようになるのです。JSONの他、YAMLファイルも選択できます。 ドキュメントをビジュアル的に作成するSwagger Editor ドキュメントを生成する方法は幾つかありますが、Swagger EditorはWebブラウザ上でビジュアル的に作成するツールになります。 左側にYAML、右側にそのYAMLから生成されたSwaggerドキュメントが表示されています。内容を編集すると、右側のプレビューにリアルタイムに反映されます。 このできあがった内容から、サーバサイドまたはクライアントになるライブラリを生成することができます。サーバサイドは以下のフレームワークに対応したコードになります。 クライアントライブラリも多数の言語向けに生成されます。こうしてみると、かつてのWebサービスで言うWSDLのようにも扱うことができるようです。 API SpecをもとにSDK化するSwagger Codegen 前述のSwagger Editorのメニューからクライアントライブラリを生成することができますが、API Specを用意しておき、コマンドラインでSDK化ができるOSSも公開されています。 Swagger Codegen こちらの手順に従って、環境準備して実施もよいですが、実際実施してみるとなかなかうまくいかない部分がありましたので、Dockerコンテナを使った方法を紹介します。 swagger-codegen-docker こちらは実際に動作することを確認しています。本ツールをスクリプト化したものは、Gistにおいておきました。 swagger_sdk_build Docker環境があるかたは、実際に試してみてください。 サードパーティーからも多数のライブラリが 公式ライブラリだけでなく、例えば Laravel向けのライブラリ であったり、 Dropwizard もあります。探せば自分の使っているフレームワーク向けのライブラリもきっと見つかるでしょう。 これらのライブラリを使うことで、ソースコード中に書いたフォーマットに従ってSwagger向けのJSONファイルを自動生成するようになります。そうすれば開発したAPIを扱うライブラリを生成できるようになりますので、APIを利用する開発者はとても容易に開発を進められるようになるでしょう。 SwaggerはすでにAmazon API Gatewayで使われるなど、APIを公開または開発するサービスにとっては無視できない存在になっています。今後ますます利用が拡大していく中とあって、Swaggerのドキュメントフォーマットに沿って進めておくことで開発者にとって利便性が高まったり、周辺ツールを利用することで開発をよりスムーズに行うことが可能になるでしょう。 Swagger | The World's Most Popular Framework for APIs.

企業がAPIを提供する上で大事なのがSLAではないでしょうか。常時利用可能な状態になければいけないのはもちろんのこと、そのパフォーマンスにおいても注意が必要です。 今回はそんなAPIのモニタリングを行ってくれるサービスを紹介します。 AlertSite APIに対するテストケースの実行であったり、そのパフォーマンスをチェックすることができます。エラーの原因などはダッシュボードで確認できますので、解決も素早く行えるようになっています。 AlertSite Runscope ダッシュボードを使ったAPIステータスのグラフ化に加えて、SlackやHipChat、メール、Webhooksといったフィードバック連携が可能です。エラーの起きた際の通知をチャットで受け取ることで素早い対応が可能になります。 Runscope APImetrics ビジュアル的にAPIコールする設定が作成できます。ワーカーも多数設定できるので複数同時コールした時のパフォーマンスチェックにも使えます。APImetrics自体APIを提供していますので外部からの自動連携も可能です。 APImetrics API Science グローバルな拠点からAPIの監視ができます。REST/JSON/OAuth/XMLなど多くのAPIに対応しています。JavaScriptでプログラマブルなチェックスクリプトが書けるのが特長になっています。 API Science Apigee Edge Apigee Edgeの機能としてモニタリングおよび解析機能を提供しています。SaaSベースまたはオンプレミスでの利用が可能で、さらにそれらを組み合わせて監視させることもできます。 Apigee Edge いかがでしょうか。APIの監視はWebサイトの監視とはまた違ってきます。各種プロトコル、フォーマットについても監視できていなければ意味がありません。 また単に生死管理だけでなく、増加していくデータ量に応じたパフォーマンスの劣化も把握することで未然の対応ができるようになるでしょう。

日本語分析などのアプリケーションを作成する場合、大量のデータを元に形態素解析など利用して制作するのが主体となります。しかしその形態素解析についても既存の解析用APIを利用することで、車輪の再開発を行わないで済む可能性があります。今回は日本語の分析系のAPIをまとめてみました。 Yahooのテキスト解析 テキスト解析では古くからあるAPIサービスの一つです。アプリケーションID毎にリクエスト数などが規定されていますので、利用にあたっては注意が必要です。 日本語形態素解析 日本語テキストを形態素解析するAPIです。特徴的なのは出現頻度情報も得られることと、品詞や名詞の単位でフィルタできる点でしょう。APIの形態素解析としては使いやすいものの一つです。 かな漢字変換 ローマ字、ひらがなのテキストから文節毎に変換候補を返却するAPIです。Web上から入力された文字を漢字変換するなどのシーンで利用できそうです。変換可能な最大文字数は80文字なのですが、十分実用的でしょう。 ルビ振り 漢字かな交じり文を解析して、ひらがなとローマ字表記を返却するAPIです。小学生、中学生などのグレードも指定できますので、テキストの読み手に合わせて解析が行えます。 校正支援 日本語テキストの校正を行うAPIです。文字の入力ミスや言葉の誤用をはじめとして不適切な表現が使われていないかなど、校正を機械チェックするのには便利な機能になります。文章入稿時やメールの送信前などのシーンで利用できそうです。 日本語係り受け解析 日本語文の係り受け関係を解析する機能を提供します。 キーフレーズ抽出 日本語のテキストから特徴的な表現（キーフレーズ）を抽出し、そのスコアも表示できるAPIです。文章からキーフレーズを抽出することで、自動でタグを付けたりするなどに応用できそうです。 gooラボの日本語解析API 名寄せや商品コメントなどを中心に、APIがそろっている印象です。使い方はシンプルで簡単に導入できそうです。 商品評判要約API：Product Review Summarization API 商品評判（コメントなど）に対して、要約してくれるAPIです。 語句類似度算出API：Japanese Word Similarity API リクエストで送られた2つの語句について、発音内容を解析比較してその類似度を0-1の範囲で分析するAPIです。人名の名寄せ確認や、商品名が多様な表記となっている場合に利用シーンがあるでしょう。 形態素解析API：Japanese Morphological Analysis API 日本語の形態素解析を行うAPIです。 固有表現抽出API：Japanese Named Entity Extraction API 人名や地名などの固有表現を抽出するAPIです。 日本語解析エンジン「なずき」 アンケート文章やメール文章、ウェブページなど、ひとかたまりの文章から「キーワード」「感性」「分野」を解析してくれる高精度テキスト分析APIです。 利用想定としては、製品サポートのメール対応で事前にメール内容から苦情か否かを振り分けたり、Webページのコメントを「不満」「要望」に分類するといったことが考えられるでしょう。 日時・地名・人名を抽出する、5W1H抽出API 日本語テキストから日時、地名さらに人名などのメタデータを数値化、正規化することが可能なAPIです。スケジュール管理や名刺管理に応用できるのではないでしょうか。他にも同サイトでは 感情解析API など日本語に対してユニークなAPIをそろえています。 まとめ いかがでしたでしょうか。各APIは似たようなものでも細かく見ると日本語特有の奥深さがあり、それぞれが特徴的です。各APIをマッシュアップすることで、新たな発見もあるかもしれません。ぜひみなさんの利用シーンに合わせて使い分けて下さい。

最近出ているWebアプリケーションフレームワークの多くはREST APIを構築するための機能が含まれています。今後新規に開発するシステムはなるべくそういったフレームワークを使っていくのが良いでしょう。 しかし社内標準の中で利用できるフレームワークが決まっていたり、すでにあるシステムに対してREST APIを実装する場合は導入が困難な場合があります。そこで今回はREST APIを構築するのに特化したフレームワークを紹介します。 これらを使うことで既存システムには手を加えずにREST API化したり、高速なAPI開発が可能になるでしょう。 Java RESTX : 軽量なフレームワークであることに加えて、REST APIドキュメントの生成、YAML形式でのテストファイル作成に対応、管理画面、モニタリングUI、Beansグラフ、MongoDB対応などが特長となっています。 Jersey : JavaにおけるRESTfulなWebサービス実装を定義する仕様がJSR 311ですが、そのリファレンス実装がJerseyになります。サーバ、クライアントそしてSpringやGuice、Apache Abderaと組み合わせて使えるライブラリが用意されています。 Restlet : RestletもREST型アプリケーションを構築するフレームワークで、クライアントとサーバがあります。Java SE/EE、Google App Engine/OSGi/GWT/Androidなど多くの環境で動作します。 PHP Tonic : PHPのクラス名、メソッド名の上にコメント形式でURLのルーティングを定義します。コードとAPIアクセスするURLとが密な結合になるので構成がシンプルになりそうです。 PSX : RAMLと呼ばれるフォーマットを使ってAPIを定義します。レスポンスはJSON/XML/Atom/SOAP/JSONXといったフォーマットに対応しています。テストやドキュメントの仕組みも用意されています。 Bullet PHP Micro-Framework : とてもシンプルなフレームワークで、柔軟なルーティングシステムとDRYの原則が用いられています。レスポンスはJSON/XML/HTMLに対応しています。 Recess PHP Framework : 完全にREST API特化型という訳ではありませんが、システム全体がRESTful PHPフレームワークとなっており、APIを作るのも簡単となっています。 frapi : 公式サイトには5分で作るRESTful APIという動画が公開されています。Web管理画面を使ってAPIが作れるのが分かりやすいです。 Python Eve : 殆ど開発不要でREST APIが構築できます。必要な場合はJSON Schemaを使ってデータの定義を行います。運用よりも開発時向けかも知れません。 Tastypie : Djangoと組み合わせて使うREST APIです。HTTPメソッドはすべて（GET/POST/PUT/DELETE/PATCH）サポートしています。入出力に使うフォーマットも多彩で、JSON/XML/YAML/bplistを提供しています。 その他 Grape（Ruby） : RailsやRackアプリケーションに組み込んで使えるREST APIフレームワークです。簡単に使えるようになっているので学習コストも低いのが利点です。 Raisin : ごく小さなREST APIを作るのに向いています。Plack上で動作するのを想定しており、簡単なDSLを使ってRESTful APIを開発できます。RubyのGrapeにインスパイアされています。 LoopBack（Node.js） : LoopBackはREST APIを素早く開発できるフレームワークで、さらにAPIゲートウェイとしての機能も備わっています。Android/iOS/AngularJSといった環境へのSDKも提供されています。 spray（Scala） : sprayも専用のDSLを使うことで簡単にREST APIが構築できるようになっています。さらにサーブレット3.0コンテナーをサポートしていることでシステムとの連携も容易になりそうです。 RESTier（.NET） : OData v4ベースのRESTサービスを.NET上に提供できるフレームワークです。企業内利用であったり、既存の.NETシステムに組み合わせるのに良さそうです。 Taffy（ColdFusion） : Taffyはちょっと珍しい、ColdFusionで作られたシステム向けのREST APIフレームワークです。これまでFlash/Flexと連携していたシステムがREST APIを公開する際に使えそうです。 Phoenix（Erlang） : PhoenixはAPIをバックエンドとしたHTML5アプリケーションを作るのに向いたフレームワークとなっています。CLIツールを通してREST APIが構築できます。 フレームワークには向き不向きがあります。そのため既存システムに手を加えてREST APIを追加するよりも、専門のフレームワークを使った方が強固で柔軟なAPI設計が可能になるのではないでしょうか。 特に既存システムに手を加える怖さはエンジニアであれば誰しもが知るところでしょう。不具合を誘発しないためにもAPIだけ切り出すのは良い選択ではないでしょうか。

今回はエンタープライズレベルでのAPIを提供する上で注意したいことを挙げています。今後BtoBなどのエンタープライズ領域においてAPI活用が進む中で、以下列挙した点に注意しておくと関係者にとって使いやすいAPIが提供できるはずです。 1. APIの仕様・ルールを統一化する APIによってインタフェースやデータフォーマットがバラバラだと、利用者を混乱させ結果としてAPIの利用促進に繋がりません。 業界標準は存在しませんが、近年ですとインターフェースはRESTで、データフォーマットはJSONもしくはXMLで、その他以下にも記載があるバージョン管理やパラメータの命名規則など必要最低限のルールを社内で整備してAPIを提供するようにしましょう。 2. 権限管理 権限管理はエンタープライズ用途でAPIを利用する場合において特に重要です。 通常、APIは一つのトークンを一人のユーザ、または一つのアプリケーションから利用する想定になっているかと思います。しかしエンタープライズにおいては複数の組織（ユーザ）が混在した環境でのAPI利用が前提となります。 そのため組織やユーザごとにデータのCRUD（参照、作成、更新、削除）に対する権限を指定できるようにしておく必要があります。例えばA組織に所属するユーザに対してはデータの参照は許可するが、更新はできないようにするなど、企業のシステム管理者がAPIに対する権限を設定できるようにしておく必要があるでしょう。 弊社ではAPIへのアクセスを安全かつ柔軟にコントロールできる権限管理機能を今年９月より提供しています。 権限管理 IAM APIに関する情報はこちら 3. ロギング APIのコール回数レベルであれば提供しているところはあるかと思いますが、企業利用においてはAPI単位であったり、ユーザ単位でどのデータにアクセスしたか、どんな操作を行ったかが記録されている必要があります。それは監査上必要であったり、インシデントが起きた際の検証用としても重要です。 APIはシステム間連携が多いため、見た目に分からないところで操作が行われたり、深夜のバッチ処理で一気にデータの操作が行われます。そのため適切なレベルでのロギングが必要でしょう。 4. SLAおよびメンテナンス時の対処 APIは自動で処理が行われますが、それでも絶対に落ちないものではありません。また、定期的なメンテナンスが行われることもあるでしょう。そのためAPI側でもSLAであったり、メンテナンス時に返すAPIについてきちんと取り決めがあるべきです。 取り決めがない場合、単純に500系エラーを返してしまってAPIを利用しているサービス側でもエラーが発生してしまいます。そうなると担当者などにエラーメールが押し寄せるなんてことも少なくありません。適切なエラー情報が提供されることで利用側でもエラー時に対応した実装ができるでしょう。 5. バージョン管理 エンタープライズにおいては特にAPIのアップデートは慎重にあるべきで、一定の指針を設けた上で適切なバージョン管理を行いましょう。通常、APIのエンドポイントの中にあらかじめバージョン番号を仕込み、新旧バージョンを区別します。システムによってはすぐに新バージョンのAPIに対応できないケースも想定されるので、新旧バージョンを平行して運用できるようにしておくべきでしょう。 6. ドキュメント 意外とAPIのドキュメントが不足しているケースは少なくありません。提供側としては十分と考えていても、利用側に立ってみると全く足りないことが多々あります。単に正確に書けば良いという訳ではなく、十分に過不足なく、利用者にとって使いやすいドキュメントを心がける必要があります。 ドキュメントはなるべくオンラインで公開する方が良いでしょう。専用の検索サーバを立てたとしてもGoogleなどの検索エンジンに敵うものではなく、利用者にとって使いづらいことが多いです。また、PSDなどだけで配布するのも検索性という意味において良いとは言えません。 7. ライブラリ/SDK ドキュメントと同様に気をつけたいのがライブラリやSDKです。APIを提供するだけでは意味がなく、各種プログラミング言語に対するライブラリ/SDKが必要です。まず提供側にとって使って欲しい環境向けに提供しますが、それ以外にも各種言語に対してライブラリ/SDKが必要でしょう。企業システムは一つの言語だけで作られている訳ではなく、多くのライブラリ/SDKが必要です。 後々のメンテナンス性を考え、なるべくライブラリ/SDKはAPIを薄くラッピングするだけに心がけるべきです。また、ライブラリ/SDKについても十分なドキュメントやサンプルアプリなどを準備しておく必要があります。 8. サンドボックス 最後にAPIを使うためのデモ環境を用意しましょう。いきなり本番環境を使ってデータを更新したり、削除するというのは利用企業にとって大きなリスクになります。なるべく本番に近いデータを自動で用意してあげたり、現状の本番環境のデータがコピーできるようになっていると理想的です。また、メンテナンス時のテストもできるようになっていると良いでしょう。 APIを使った開発は一度終わったら完了ではなく、継続的に更新したり追加開発を行うものです。サンドボックス環境も30日限定などではなく、いつでも常に使えるようになっている必要があるでしょう。 APIの利用を社内に限定するだけでなく、社外に公開してビジネス展開する場合には、上述したポイント以外にも留意すべき点は多いと思います。特に従来企業内にあったデータを解放するとなった場合、それまでとは全く違うレベルでの運用が求められるはずです。 単に公開すれば良いという訳ではなく、周辺技術や利用企業の開発/運用利便性を考えた上でAPIを提供しなければなりません。

ここ数年、決済APIが熱いです。APIで提供することで手数料もごく安く、かつすぐに自動化ができるようになります。Eコマースはもちろん、デジタルコンテンツや会員定額決済など様々な使い方が考えられるでしょう。 WebPay とにかくシンプルに決済できるサービスです。PHP/Ruby/Python/Java/Node.jsなど多数のプログラミング言語向けにライブラリが提供されています。スタータープランであれば月額固定費はなく、3.25%の手数料のみとなっています。 coincheck payment ビットコインに特化した決済サービスを提供しています。EC-CUBEなどに組み込んで使うこともできる決済モジュールも用意されています。執筆時点（2015年10月時点）ではβ中とのことです。 SPIKE（スパイク） 決済手数料がなんと0%というのが売りのサービスです（上限は月額100万円まで）。ライブラリは Ruby版 、 PHP版 がありますが、どちらもコミュニティベースとなっています。 PAY.JP 2016年5月末までは手数料0%となっています。RESTfulかつJSONで使えるAPIを提供しています。ライブラリはRuby/Python/PHP/Javaについて提供されています。 オールマイティ 決済型としては即時、月額課金が可能となっています。またカード番号をIDとして記録しておき、2回目以降の決済ではIDを使ってカード番号入力の手間を減らすこともできるようです。 Yahoo!ウォレット FastPay Yahooが提供するので安定性や信頼性においてはレベルが高いと思われます。PHP/Ruby/Pythonに対応したライブラリが提供されています。決済手数料は3.25%となっており、全体的にWebPayを強く意識したサービスとなっています。 Stripe 日本でもまもなく開始すると思われる決済サービスです。グローバルではすでに年間数十億ドルを処理するレベルとなっています。グローバルサービスとあって130カ国以上の通貨に対応しているのが利点です。 PayPal(ペイパル) Paypalは言わずとしれた決済サービスです。最近eBayから独立し、さらに拡大の勢いを見せています。画像を貼り付けて決済するのが基本ですが、APIを使った操作にも対応しています。 Webサービスなどで収益をあげる場合、何らかの決済システムを導入するでしょう。昔であればASPと契約し、数ヶ月かかって構築されていましたが、最近ではごく簡単に素早く決済機能が実現できます。ぜひチェックしてみてください。

加藤です。 最終日のレポートです。 -Technology Keynote & Panel Disccussion Apigee CTO Anant Jhingran さんが登壇。APIに関連する技術のあるべき方向性などを話されていました。 また、パネルディスカッションでは、Amazon API Gatewayとの比較の話も出ました。 以下はポイントとなるキーワード。 -API MICROSERVICES WITH NODE AND DOCKER Tony Pujals, Atomiq こちら深い話を期待したのですが、Dockerの使い方を中心の話となりました。 スライドは、 こちら ただ、丁寧なスライドですので、わかり易いと思います。 -DEVELOPING A BETTER DATA COLLECTION API Peter Reinhardt,Segment.io こちらも、モダンなAPIにおけるデータコレクションのあり方(部分更新などを考慮した)という講義を 期待していたのですが、過去の振り返りに近い内容で、あまり新しいところはなかったのが残念。 -END TO END TESTING: BUG SQUASHING FOR API DEVELOPERS Ozan Seymen and Saul Zukauskas, Apigee こちらは、I Love APIsに参加したメンバーによると、実質的なREST API Testツールの紹介などあり面白かったと聞いています。 apickli - REST API integration testing framework based on cucumber.js 具体的な内容や使用レビューは、また本ブログで共有します。 -BUILDING PREDICTIVE APPS WITH LAMBDA AND MICROSERVICES ARCHITECTURE Alan Ho, Apigee こちらは、AWS LAMBDAのことかと勘違いしていましたが、 Lambda Architecture というのがあり、 過去のデータと最新のデータを分析してリアルタイムにAPIで公開するというデモでした。 レコメンデーションAPIを作るときに参考になるアーキテクチャーです。 簡単には、 Historical Dataを、Batch Layerで処理 Recent Dataを、Speed Layerで処理 公開 Dataを、Serving Layerで処理 という感じです。 NetflixのレコメンデーションAPIによるLambdaアーキテクチャー利用例 デモのLambdaアーキテクチャー利用例 これぐらいならば、すぐ作れそうな感じです。 -APIGEE AND NODE.JS: BUILDING MOCK BACKENDS FAST Saul Zukauskas,Apigee こちらは、API開発する際による起こる、APIモック(スタブ)が欲しいなぁ、というときの 解決策として、OSSツールとしての紹介です。 これは、割としっくりきました。 こちらも使用レビュー感について、また当ブログでレポートしたいと思います。 Example project for mocking legacy backend services with Apigee and Node.js バックエンドAPIは、モンスターになりえる、という絵。開発している人はわかりますよね(笑) amockコード例 以上、日程終了しました!! まだまだ、レポートしきれてないところはありますが、おいおい情報提供していきたいと思います。 また機会があれば、参加したいと思います。 カンファレンス終了後の夕焼け。会場の真上を飛行機が飛んでます。

加藤です。 引き続きレポートです。 -Throwing Down the Gauntlet on Digital Experience:B2B Bill Gajda, Visa Corp. Srinivas Ramadath, Accenture Digital Jennifer Kinney, MapQuest による座談会。 B2BにおけるAPI導入をどう促進するかという話を中心に話がありました。 トピック的には、 B2BにおけるUberは誰になるか データを集めて、分析し、結果をAPIを出すような取り組みが出てきている アリババなどはその実例(eCommerceの商取引データを分析して、他企業/産業で活かす??) という感じです。若干物足りないところはありましたが、B2Bはこれから。盛り上げていきましょう!! -USING CONTAINERIZATION TO ENABLE YOUR MICROSERVICE ORIENTED ARCHITECTURE Jonathan Bennett,Zooz Greg Brail, Apigee Zooz のJonathan Bennettさんによるコンテナサービスの 利用状況を紹介。 kubernetes , mesos などコンテナスケジューラとして紹介。 Zooz自身のプラットフォームアーキテクチャーとしては、以下の写真の通り。 API Facade下の各モジュールは、コンテナ上で稼働していると思われます。 スケジューラによるマルチホストにおける運用方法、苦労点などを詳細を聞いてみたいところです。 -TRANSFORMING YOUR BUSINESS THROUGH APIS Ramachandra Koty,Equinix Senthil Baladrishnan,Equinix Purvish Purohit,Equinix によるEqunixさんによる、API活用の講演。 Equinixさんは、先進的な取り組みをされていて、興味深い内容でした。 基調講演でもApigee CEO Chetさんと登壇されたEquinix CIO Brian Lillieさんの スライド にもあるように、 Interconnection APIs Datacenter & Collocation APIs Digital Content APIs Marketplace APIs eCommerce APIs Operation & Analytical APIs Administration & Security APIs を揃えてるようです。詳細は以下参照ください。 また興味深い話として、Dockerコンテナによる取り組みが紹介されていました。良い取り組みです。 そして、SDK。戦略として、当然ですね。 -UNLOCKING VALUE FROM IOT WITH APIS Abhi Rele, Apigee John Calagaz,Centralite IoTでもとめられる要求機能的な絵。 そして、ApigeeさんIoT基盤Apigee LinkとCENTRALITEさんとの協業で生まれたjiliaの紹介。 Jiliaのアーキテクチャーはざっと以下の模様。 最後は、OSSである Node-RED のデモ。Node-REDは面白いIoT促進ツールですので 皆さんも機会あれば、使ってみてください。

加藤です。 KeyNoteのあと座談会KeyNoteがありましたが、参加されてる企業にてデジタルカルチャーは存在するか というざっくりしたテーマでの座談会でしたので、割愛して各セッションをレポートしていきます。 Microservices at Amazon Chris Munnsさん@Amazon Business Development Manager - DevOps 各企業がMicroservicesを活用しつつある。 以下知らないのもあったので、別途使ってみたいと思います。 Microservicesは、以下のポリシーで。APIのみで制御する。ここ重要ですね。 Microservicesと、SOA(Service Oriented Architecture)の比較。わかりやすい。 文化とプラクティスとツールが必要。 文化: オーナシップと責任。自ら実行。小さなチームで。ベストプラクティスを、ただフレキシブルに。 プラクティス: 継続的なインテグレーション & デリバリ ツール: CI & CD Tools、インフラマネジメント、ホスト、サービス、ビルドMetrics/Monitoring/Logging、ConsumptionとCollaboration Amazon API Gateway使ってます。と言ってましたが、内部でも使ってる模様です。 絵は一般的なものなので割愛。 全体のトーンとして、Microservicesとしてのお作法に近い話でした。個人的には、もう少しAmazonでの Microservicesを使ってるサービスなり、トランザクション管理(スケジューラー)など深い話を期待してましたが、 少し残念。 この辺り、また話が聞ける機会があれば、レポートしたいと思います。