初めまして! 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を使ってるサービスなり、トランザクション管理(スケジューラー)など深い話を期待してましたが、 少し残念。 この辺り、また話が聞ける機会があれば、レポートしたいと思います。

加藤です。 速報、という感じでなくなってしまいましたが、本日の状況をお知らせします。 本日も晴天なりで、朝から暑かったです。ここが基調講演会場のSan Jose Convension Centerです。 Keynote始まる直前です。お洒落なBGMがあり、会場を盛り上げます。このあと暗くて写真とれませんでしたが、 暗闇の中、ダンスの催しでオープニングでした。 Apigee CEO Chet Kapoorさんが登壇です。 これ結構すごい表現です!! 働くアーミーからものづくりができる人のネットワークへ。APIを介して、 合従連衡的に、自社、パートナー、エンドユーザとつながってエコシステムを形成をというメッセージかと。 いかにして働くかに。ビジネスでデジタルを活用していく。 IoT等が進めば、データの処理は人では間に合わないので、当然マシン(機械)で、インテリジェントに処理を。 Cognitive Computing & AIの世界です。それとAPIを絡める。 そして、デジタルはすべての産業をDISRUPTする、すべての産業を劇的に変えていく。決め文句として使っていきたいと思います。 最後は、EquinixさんがAPIの取り組みを紹介。詳細は別速報にてご紹介します。

加藤です。 引き続き10/12午前中の内容です。 API開発に関わるコンサル数値的な情報をお届けします。 DeloitteのAPIトレンド2015抜粋 そして、時代と共に変化するソリューションとテクノロジ。 現代のREST APIの位置付けと過去のEDIやSOAとの違いを一枚で説明。 Gartner Hypeサイクル。ちょっと斜めになってますが・・・ 世界の各地域の開発者状況。アジアとアフリカは平均年齢が27歳。日本も含まれるので、有望?! メジャーなアプリ領域において、興味深い「稼げる」分布図。モバイルAppは、B2Cなので少額金額なのは わかり易く、クラウドサービスはB2B系で高額金額に割とよっています。 IoTは、どちらかというとモバイルAppよりで少額か、まだまだ稼ぐところを見つけるのがこれからということが 言えそうです。 でこの手の世界は、デベロッパーが真の意思決定者になるべきと。これはしっくりきます。 デベロッパーによる意思決定プロセス分解。

加藤@サンノゼです。 加藤は、Masterclass How to Build Successful Developer Programsに参加しており、その速報です。 てっぺんの三角のスコープのお話です。 調査会社のEDC(Evans Data Corp.)によるUnderstanding the Development Landscape for APIsという講演です。 2021年には全世界で、2650万人規模に開発者が増加、APACが伸びてます。 IoTに関する開発はAPACと北アメリカでかなり活発化しそうな感じです。 Hot Topics セキュリティ、IoT、Big Data、 Real-time Events、Congnitive Computing & AIの5つが熱い分野でしょう、と。 開発者とのリレーションがますます必要となり、開発者とのリレーション(DevRel)に必要なことを紹介するサイトのようです。 devrelate

加藤@サンノゼです。 I Love APIs 2015が始まりました。 速報を伝えてきます。 ホテルからの眺め。田舎町であります。 入場は結構アバウトで、名前検索するだけでバッチ発行です。アメリカ的です。 会場の真上に飛行機が横切ってきます。 スタバコーヒー、ヨーグルトとかあり、参加者には助かります!!

ども、Enteprise APIs Hack-Night事務局 兼 APIゲートウェイ担当の加藤です。 10/12-10/14 サンノゼにてApigeeさん主催のI Love APIs というカンファレンスが開催されます。 I Love APIs たしか、今年で3回目?だったかと思いますが、過去の開催は加藤自身は諸都合で参加できず、今回は楽しみにしております。 Microservicesネタ、Node.js/Swaggerネタ、IoTネタ、B2B/B2CビジネスでのAPIユースケース、 Developerコミュニティ形成ネタなど、APIに関する盛りだくさんの内容が3日開催されるようですので、 まずは速報で毎日お届けしようと思います。 お楽しみにしてください。 それでは!!!