先日、 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日開催されるようですので、 まずは速報で毎日お届けしようと思います。 お楽しみにしてください。 それでは!!!

JSON Schemaを作らなければと思っても、つい面倒で先送りにしてしまいがちです。単なるシステム上だけでなく副次的に開発補助の仕組みがあれば、作る意欲もわくでしょう。そこで今回はJSON Schemaファイルを読み込んでAPIドキュメントを生成してくれるソフトウェアを紹介します。 iodocs node.jsとredisの組み合わせで動作します。JSON Schemaファイルを置いておくと、その内容をHTML上に整形して表示してくれます。Webブラウザ上から実際にAPIをコールすることもできるようになっています。 matic maticはnode.jsで作られているコマンドで、特定のフォルダとディレクトリの配置によってJSON SchemaをHTMLドキュメント化します。 JSONSchemaDocStylesheet JSON Schemaに対してXSLスタイルシートを適用することでHTML化するという試みです。今はJSONを一旦XML化し、その後XSLスタイルシートを適用します。 Prmd PrmdはRubyのライブラリで、HTMLではなくMarkdownドキュメントを出力します。JSON Schemaファイルが複数に分かれていても扱えるので、大型化しても運用しやすそうです。 Jdoc JdocもRubyのライブラリで、YAMLファイルに定義した内容からAPIドキュメントを生成できるようになっています。 Docson JSON Schemaをドキュメント化すると言うよりも、構造をHTMLを使って見やすくしてくれるツールと言った感じのソフトウェアです。Swagger向けにAPIドキュメントとして生成する機能もあります。 今回紹介したソフトウェアを使うことでAPIドキュメントを作成するコストが大幅に下がるようになります。システムとドキュメントの乖離が避けられればメンテナンスコストも低くなるでしょう。ぜひJSON Schemaを用いた開発の際に使ってみてください。

昨今、APIの重要性は高まるばかりです。プロジェクトの大小にかかわらず、APIはどこかで使われているのではないでしょうか。そこで今回はAPIの設計手順について見ていきたいと思います。APIをはじめて設計される方はもちろん、これまではなんとなく設計してきたという方もぜひご覧ください。 APIとRESTについて 最近、APIではよくREST APIや単にRESTといった単語が聞かれるようになっています。RESTとはHTTPプロトコル規格の主要著者の一人であるRoy Fielding氏が提唱したことで有名です。そのFielding氏のREST原則通りに構築されたシステムはRESTfulと呼ばれます。その経緯などの詳細は Wikipedia に譲るとして、最近は以下のように包括されているようです。 Fielding氏のRESTアーキテクチャスタイルの原則に合わせたWebサービスシステム RPCスタイルに合わせた簡易な XML+HTTP インターフェイスを採用したシステム（SOAPは使わない） 本稿では、RESTアーキテクチャスタイルの原則には沿っていません。また、APIをHTTPでのステートレスなクライアント・サーバプロトコルとして、包括的な話を進めていきます。 API定義書 API定義書は開発がはじまる前までに、たとえ資料の納品の必要がなかったとしても作成した方がいい資料です。現場サイドであらかた決めておくだけでも開発の進みやすさが違うでしょう。後から作成するなどといって先送りしてしまうと、後になって振り返りたくなってもできなくなってしまいます。 API定義書作成のベストプラクティスを上げるとすれば、コーディングとテストを行いつつ、それを定義書に落とし込めるツールになるでしょう。以下に主なツールを紹介しておきます。どれも一長一短ありますので、プロジェクトにあったツールを選定してみてください。 Swagger | The World's Most Popular Framework for APIs. mashery/iodocs r7kamura/autodoc エンドポイントの設計 パスに含めるのはどれ？ パスやクエリパラメータに含める情報については、APIを構築する言語や利用するフレームワークよって左右されてしまうことがあります。例を紹介します。以下はどちらもユーザプロファイルを取得するAPIとします。109876はユーザIDです。 // 1．IDをパスに含めるケース http://abc.com/v1/user-profile/109876 // 2．IDをクエリに含めるケース http://abc.com/v1/user-profile?id=109876 この場合、ユーザIDをシステム側がどのように取得するかによるのですが、最近の開発言語でのフレームワークでは殆どが1のパターンをルーティング処理で対応できるようになっています。実際、1の方がメソッドでの項目利用やバリデーションのフック処理などで対応しやすいと思います。 ユーザIDなど特定のIDを検索するパターンならば上記で十分です。では、ユーザ一覧を取得する場合はどうでしょうか？ここでは、10件目から20件を取得するケースとします。 // 1．IDをパスに含めるケース http://abc.com/v1/users/10/20 // 2．IDをクエリに含めるケース。offsetは何件目から取得するか、maxは取得件数を意味しています。 http://abc.com/v1/users?offset=10&max=20 1のケースはパッと見て何がしたいのか良くわかりません。このケースでは2の方が分かりやすいかと思います。 このように、操作内容によってどちらに含めるのかを考慮しましょう。基本的には、エンドポイントをデフォルトで接続した場合を考慮し、それ以外の操作は可変パラメータを渡すようにしましょう。 エンドポイントにはバージョンを含めよう APIを広く一般ユーザへ公開する場合には、バージョンを含めましょう。このバージョンを入れることで、APIの切り替えなどがスムーズになります。多くのサービスをみると、バージョンはAPIサービス名のすぐ後に入れるのが一般的なようです。たとえば次のようになります。 http://abc.com/api/v1/… http://abc.com/api/v2/… もちろん、企業向けのイントラサービスでAPIを利用する時もバージョンを入れておいた方が良いでしょう。詳しくは 適切なAPIを設計するために注意したいこと「バージョン管理、同期・非同期」 - NTT Communications Engineers' Blog を参考にしてください。 APIの命名規約など それを見て動作が想像できるか APIの命名については、アプリでメソッド名を作るときと同様に考えます。分かりやすいメソッド名は、その後の綺麗なコードを生み出します。 項目名もわかりやすく これも良くあるパターンがiとかc1などと言った1〜2文字で作成するケースです。queryをqとしたりするのはありかなと思いますが、何に使ってるのか、想像できない項目名はやめた方が良いでしょう。とはいえ、長すぎも厳禁です。長すぎるAPIは見た目も美しくありませんし、定義書を書く時やコーディングする時も面倒でしょう。 命名にあたりAPIでは名詞として複数形を利用するのが一般的になっているようです。 キャメルケースかスネークケースか、はたまたスパイナルケース？ 命名についてはいくつかの法則があります。 ケース名 例 キャメルケース userProfile スネークケース user_profile スパイナルケース user-profile これははっきりいって個人の趣味ではないかと思います。 GoogleのSEO対策として、スパイナルケース（ハイフン繋ぎ）だと単語として認識するといわれています。そこが気になるのであれば、スパイナルケースが妥当でしょう。しかしこれが本当であるかははっきりしていません。プログラマの感覚としてはGoogleがスパイナルケースしか対応しないとは考えられません。 もしJavaScriptでの規約に合わせるなら、先頭小文字のキャメルケースが良いでしょう。このように、その時の開発言語に沿って決めてもいいかと思います。 最後に API設計の導入部分を見ていきましたが、いかがだったでしょうか？最初の設計では多くのものを定義する必要があります。本文中にも記述しましたが、フロントとバックエンド側を繋ぐI/Fを早々に決めておくことが、プロジェクトの並行開発になによりも必要になります。 また、アクセスの考慮やセキュリティの問題など他にも考えるべきポイントは数多くありますが、それは今後紹介していきます。ぜひ参考にしてください！

JSONはAPIとのデータ授受に利用されるメジャーなフォーマットになっています。それだけにシステム開発の際にJSONを扱う機会も増えているでしょう。 そんな時に素のJSONファイルは見づらく、構造を見誤る可能性があります。そこで使ってみたいのが今回紹介するソフトウェアたちです。 zaach/jsonlint JSON Lintはその名の通り、JSONファイルのチェックをしてくれます。インストールは npm install jsonlint -g で、jsonlintコマンドにJSONファイルを渡すだけです。 $ jsonlint myfile.json JSONView - Chrome ウェブストア JSONViewはGoogle Chrome機能拡張で、JSONファイルを表示する際に素のテキストではなく、ハイライトと整形した状態で表示してくれます。同じような機能拡張やアドオンは各ブラウザに存在しますのでインストールしておくのが良いでしょう。 lloyd/yajl YAJLはJSONライブラリですが、YAJLをインストールすると一緒に入るJSON Verifyが便利です。これはJSONファイルが構造として合っているか検証してくれるコマンドです。手作業でJSONファイルを作った際にはまずJSON Verifyでチェックしておくと良いでしょう。 jq jqはCLIで使えるJSONパーサーで、CSSセレクタのような記述でJSONデータの絞り込みができます。JSONデータは目視では構造を見誤ることが多いので、jqを通してきちんと確認しておくのが良いでしょう。 typicode/json-server JSON ServerはJSONファイルを使ってRESTfulなWebサーバを立ち上げます。JSON Schemaではありませんが、モックデータを適用することで開発時のモックサーバとして使うこともできます。 json_pp - search.cpan.org JSON PPはCLIでJSONを整形表示してくれるソフトウェアです。ローカルにあるJSONファイルをcatで表示すると分かりづらいですが、JSON PPを使えば見やすくなります。 いかがでしょうか。JSONの普及が進んでいることもあって、多くの周辺ツールが開発されてきています。これらのツールを使うことで生産性が大きく向上するのではないでしょうか。 ぜひ皆さんの開発に役立ててください。

最近進んでいる企業におけるAPI活用情報を共有し、さらに発展させていこうという取り組みが Enterprise APIs Hack-Night です。先日、その第一回目のイベントがありました。今回はそのイベントレポートになります。 最初にEnterprise APIs Hack-Night事務局 加藤さんより開会の挨拶がありました。 ビジネスのデジタル化におけるAPI活用事例 by Apigee Japan 清水さん 最初にキーフレーズとして「あらゆるデジタルビジネスはAPIが動かしている」をあげました。「ユーザーにシームレスな体験を届けるのは難しい」とした上で、幾つかの実例を紹介されました。 シームレス体験の例 車に乗っている人のApple Watchに、処方箋を出した薬局から薬の準備ができたと通知が来ました。薬を取りに行った際に、店舗にあるプリンタで子供の写真をプリントしました。そうする内に病院で予防接種を受ける時間になり、病院に向かいました。これまでの一連の流れがある企業のシステムと統合されまして、ポイントを獲得しました。 以上のようなアクションを起こす際に、様々な企業のシステムと企業外のシステムが関係してきます。外部または内部の多くのシステムが関係してくるので、1つのアプリでさえ、スパゲッティ状態になってしまいます。スパゲッティ状態では関連するシステムのどこかに不具合が起こると、シームレスな流れが止まってしまいます。そこで、APIを管理するレイヤーを一層設けて、スパゲッティ状態を整理してアプリケーションを使いやすくするサービスを提供しています。 先に紹介した例はアメリカのWall greenの事例で、Wall greenはコンビニエンスストアと薬局が一緒になったような企業です。事例の中の「処方箋ができました」という通知は処方箋APIで動いています。もちろんAPIだけでなく、外部内部の様々なリソースで動いており、自分の体験はどこかで繋がっているとユーザーに実感してもらえるようになります。 AP通信社（独立系の非営利通信会社） ニュースを探してきて記事を書いて提供するアフィリエイト企業とのつながりを広げていきたいと考えでした。レガシーのシステムと繋げるのは難しいため、バックエンドシステムをAPI化してつながりやすくしました。外部のパートナー企業とのつながりを広げるのももちろんですが、社内のシステムBtoE（Business to Employee）も推進しています。 Salesforce (CRM大手) 社内のシステムが古くなっており、バックエンドのシステムを新しくしたいと考えていました。アプリベースのサービスを作り、CRMサービス提供企業として、自社内の業務効率を上げていきたいと考えています。社内向けのシステムを新しくするときにもAPIは使えます。 Dell 製造データ、ビジネスパートナー（再販事業者、代理店、サプライヤーなど）とのコミュニケーションを取る上でリアルタイム性に欠けているのが課題でした。APIを活用することでリアルタイム性を実現しています。バックエンドに手を入れるのはコストと時間がかかり、APIを管理するレイヤーを加えることでバックエンドを改修しています。 ベッケル社 (巨大建造物を作る建築エンジニアリング会社) API導入以前、図面の修正は事務所に戻ってしており、工事の効率が上がりませんでした。工事管理責任者にiPadを支給して、iPad上で走るアプリを自分たちで制作しています。例えばコンクリート工事の進捗を見る場合、コンクリートを埋めるときにセンサーを入れ、そこから送られてくるデータで進捗を確認する。建築現場では協力会社など多くの他社とも関わりますが、他社の人にはデータの出し分けをして、管理をしています。 質疑応答 質問：BtoEの話ですが、コストダウンのために行うのか戦略的に行うのかどちらですか。 回答：両方だと思います。まずはコストダウンです。独自アプリを作る際にAPIは適しています。最終的には外部パートナーと繋ぐ流れが見受けられます。より先端の企業は完全にAPIをパブリックにしています。APIを元に個人や企業が開発し新たなビジネスを作っていこうとしています。 質問：セキュリティ面が気になります。 回答：一番重要な点になると思います。私たちのプラットフォームも重要な機能として備えています。APIを作る上でバックエンドも安全でなければならないと思います。 APIがNTTコミュニケーションズのサービスを進化させるby NTTコミュニケーションズ　緒方 宏明 弊社の緒方が登壇しました。 通信キャリアにおけるAPI 世界的にみて通信キャリアが提供するAPIは増えてきています。 2015年現在、通信業界におけるAPI市場は500億ドル程度ですが、3年後の2018年通信業界のAPI関連の市場規模が1570億ドルになると見込まれています。 Business Process API 通信キャリアには販売代理店、SIer、法人企業、コンシューマーなどのお客さまがいます。AT&TではAPI関連収入の80%が主要代理店10社で占められているというデータもあり、キャリアにとって販売代理店は重要なお客さまの一つです。なので各通信キャリアは販売代理店が望む契約情報やサービスオーダーをAPI経由で情報取得できるBusiness Process APIをはじめに整備していきました。 通信キャリアならではの機能系API 次にネットワークやクラウドなど通信キャリアならではの機能系APIを整備しています。そして最近ではM2M/IoT、Web-RTCなど新しい分野・技術に関するAPIの拡充を進めています。 海外の主要キャリアのAPI提供状況 AT&TやOrangeなどでは、Business Process系、認証認可系、機能系APIなどのコアAPIの提供は一通り完了しています。 APIをEnterprise用途で使ってもらうために必要なこと APIの仕様ルールを統一し、社内のルールとして規定していくこと、提供するAPIをマネージメントすること、アクセス制御などセキュリティ機能を充実させることなどがあります。 APIをマネジメントすることとは 　APIをマネジメントするとは自社で複数のサービスがあってそれを提供する場合、各サービスでバラバラに管理するのではなくて、管理ツールによって一元的に管理することです。管理対象は認証、ログ、セキュリティ、アクセス権限、トラフィック制御などです。代表的な管理ツールは、この開発者ブログでも紹介しているので参考にしてください。 お客様の個々のアクセス権限管理 Enterpriseでは参照できるAPIを限定的にしたり、参照はできるが更新・削除はできないなど、きめ細やかな権限管理が必要になってきます。業務要件はお客さまによって異なります。ですのでお客さまご自身で柔軟にアクセス権限を設定できる仕組みが重要であると考えます。 情報やイベントをリアルタイムに提供する REST APIだけでなく、イベントが発生した時に自社のサービスからお客様にプッシュ通知する仕組みもEnterpriseでは必要であると考えます。通知する仕組みとして代表的な技術にWebhookがありますが、今後弊社としてもWebhookを活用したアプリケーションtoアプリケーションで情報を提供する仕組みを整備していきたいと考えています。 APIによって進化し始めているNTTコミュニケーションズのサービス 当社ビジョンの主要強化施策の一つにAPIの充実化がありまして、全社をあげてAPIの充実化に取り組んでいます。提供中のAPIはビジネスプロセス系、機能系（クラウド、ネットワーク、ボイス、アプリケーション）などがあります。 お客さまにAPIを提供する際には、APIゲートウェイで認証やデータフォーマットなどを統一化しています。APIゲートウェイは日本・アメリカ・ヨーロッパの3拠点で展開しており、グローバルシームレスに利用可能です。 近々にAPI権限管理をリリース予定（9/10リリースしました）で、さらに安全に便利で使いやすく、今後もNTT Com APIは進化していきますので宜しくお願いします。 IoT/M2M分野におけるWeb APIの使い方とデモ by MOONGIFT　中津川 篤司 さん IoTの特徴 IoTとは Internet of Thingsの略。ネットワークが根幹にあります。 M2Mとは Machine to Machineの略。マシンとマシンをつなぐというよりは、クラウドを挟んで、MtoCtoMの方が意味があるのではと思います。 ネットワーク 無線なのか有線なのか？近距離なのか中距離なのか？ハブ型なのか単体なのか？それによってネットワークの種類を設定することがIoTの基本です。 また、ネットワークの別の観点でプロトコルがあります。とにかくデータ量が多いので、データ量を減らして、双方向性で信頼性を高くしたいです。UDPよりPCPが使われます。 MQTTとは Hub-Sub型、httpに比べてヘッダのデータ量が少なく（2バイト）、N対Nでネットの送受信ができます。中間にブローカーがおり、データを出力するパブリッシャー、データを受け取るサブスクライバーがいます。パブリッシャーは同時にサブスクライバーになることができます。パブリッシャー、サブスクライバーはトピックを持っています。例えば、cat1にパブリッシャーが発信するとcat1を購読している人だけが受け取ることができます。 IoTデバイスの特徴 低消費電力。小さい。遠隔地に置く。安価。 IoTにおけるweb APIとは ビッグデータ型 デバイスのIDとトークンを持たせて、センサーからのデータをネットワーク上に投げるのみです。データがあまりにも膨大になりすぎてしまう恐れがあるので、閾値判定程度は行えます。また、一時間に一度だけデータをアップしたいという要望がよくありますが、一度にアップするとサーバが落ちたり、遅延が発生したりします。グループごとに起動するタイミングをずらすようにして対応します。基本はget/postでエンドポイントが1つです。httpsや MQTTSを使います。デバイスをトークンにかませます。 スマートフォン型 Beacon系のデバイス。デバイスは情報を発信するだけです。動いているかどうかの生存確認が困難で、検証が難しいです。スマートフォンにアプリを入れなきゃいけないのが厄介な点です。最近、山手線アプリが行っていたサービスで、電車の中でアプリを立ち上げるとポケモンがゲットできるものがありました。乗っ取りの恐れがありますので、クリティカルな要件では注意が必要です。https・outh・プッシュ通知などが使えます。 ホームオートメーション 最近よく耳にするスマートホームという言葉には2つの意味があります 地域や家庭内のエネルギーを最適制御する住宅。 家電などを情報化する。 今回は2の意味になります。 ドアを開けたら家の明かりがつくなど、ホームオートメーションの多くは自宅がトリガーになります。そのため、ネットワークは使いますがインターネットを使いません。一つ、インターネットを使うものが、おじいちゃん・おばあちゃんの状態を遠隔で監視して、閾値を超える行動があると息子・娘のところへプッシュ通知を飛ばす高齢者の安否確認システムではないかと思います。 音声による制御 Rasberry Piにjulius（音声認識エンジン）を入れます。マイクに音声を入れて、Rasberry Piでテキスト解析して、内容によってRiキット（赤外線通信を出すデバイス）で照明を消すことができます。 MQTTで合成音声チャット speakAPIをつかって、Rasberry PiとChromeで会話することができます。一人でしりとりも出来ます（笑）。 ライトニングトーク 懇親会で行われたライトニングトークをご紹介します。 1. レガシーなアプリにAPIを実装 請求書発行のクラウドサービスの会社でWeb APIを実装した際に苦労しました。Seasor2を拡張し、主要な機能のみ対応しました。参加されている方のご意見を聞きたいです。 2. Enterprise × APIs API利用者はデザイン思考とビジネス思考が必要です。Enterprise APIは法人同士が使うAPIと考えています。企業間を結ぶAPIビジネスをやりたいと思っています。コミュニティ活動でコミュニティをつなぐことは自分の思考にもマッチしています。 3. 5分でわかるWeb RTC Web RTCとはリアルタイムコミュニケーションをソフトウェアエンジニアが自由に使えるものです。Webサイトやアプリに組み込みができ、コミュニケーションアプリや家電・IoTなどで使えます。 4. APIをEnterprise用途で使うために APIをEnterprise用途で使うために有用なソフトNode-RED( http://nodered.org/ )の紹介です。IoT用と言われていますが、様々なAPIを実行することができます。 5. APIとマーケティング API MeetupでUnityとPaypalの連携デモを行ったら、バズりました。せっかくのテスト環境をハッカソンなどで使うことで、思わぬ発見があります。 6. NTTネットワークサービスシステム研究所の取り組み 重厚長大でなく、組み合わせでつくります。アーキテクチャ、既存のものをどう出していくか、仕様の統一をすることが必要です。APIはインターフェースを使ってつくります。APIは叩いてみないとわからないので、叩いてみます。 次回は12月04日を予定しています。皆さまお誘い合わせの上、ぜひご参加ください！また、 Enterprise APIs Hack-NightはSlackにてオンラインコミュニティを提供 しています。ぜひこちらもご参加ください！ Enterprise APIs Hack-Night - connpass

既にWebシステムが稼働している中でREST APIを追加するというのは工数がかかります。そこで使える手段としては、 APIゲートウェイ製品・サービスの利用 RESTフレームワークの導入 という選択肢が考えられます。今回はその中でもRESTフレームワークを導入するのに使えるフレームワークを紹介します。 WordPress › WordPress REST API (Version 2) « WordPress Plugins WordPress REST APIをインストールすることでWordPressにREST APIを追加することができます。WordPressをCMSとしてアプリから使ったり、フィードとは違って他のシステムからデータ投入もできます。元々WordPressではXML-RPCがありますが、ライブラリもそれほど多くないのでWordPress REST APIのが使いやすいでしょう。 cookpad/garage GarageはRailsアプリケーションに組み込んで使います。リード/ライトアクセス制御であったり、簡単にRESTful APIを実装できるようになっています。ロジックは自分で書くのでより実践的なAPIが作れるようです。 API Guide | restify node.jsアプリケーションにREST APIを追加するモジュールです。node.js向けWebアプリケーションフレームワークというとExpressが有名ですが、restifyはAPIに特化しているのがポイントです。 Django REST framework Djangoで作ったシステムに手早くREST APIを組み込めるのがDjango REST frameworkです。既存のモデルをそのままAPI化する時に便利そうです。バージョニング、ページネーション、フィルターなどカスタマイズする機能もあります。 Tastypie - RESTful APIs for Django TastypieもDjangoにRESTfulなAPIを追加するライブラリです。GET/POST/PUT/DELETE/PATCHをすべてサポートしています。やり取りするデータフォーマットとしてJSON/XML/YAML/bplistがサポートされています。 dingo/api PHPのフレームワーク、LaravelにREST APIを手軽に追加できるライブラリです。REST APIだけでなく、OAuth 2.0の実装も可能で、JSON以外のフォーマットにも対応しています。API Blueprint対応のドキュメントも生成します。 Luracast/Restler 任意のPHPアプリケーション向けにRESTful APIを提供します。OAuth 2.0もプラグインで提供されています。APIの利用制限機能、JSONPサポートであったり、入出力フォーマットにJSON/XML/Yaml/Amf/Plistが選択できます。 RESTフレームワークは著名なソフトウェア（WordPressなど）やフレームワークごとに存在するようです。使っているフレームワークに合わせてライブラリの選択をすれば、WebシステムのAPI対応も素早くできるのではないでしょうか。

2015年9月10日に、NTT Com APIゲートウェイ 権限管理機能をリリースしました。 本機能を利用することで、お客さまご自身でNTT Com APIに対するアクセス制御が設定できます。 アクセス制御は以下の通りきめ細かに設定できますので、お客さま個々の業務用件を満たす柔軟なアクセス制御が可能となります。 API単位 アクセス権限の対象として複数のAPIを指定することができます。さらに詳細な設定としてREST APIのメソッド(GET/POST/PUT/DELETE)や、リソースパスも指定することが可能です。 IPアドレス単位 お客様が利用されるアクセス元IPアドレスを複数指定することができます。 任意のデータ単位 JSONペイロードやヘッダのうち、利用を許可したいデータをキー、バリューの組み合わせにて指定することができます。これによって、契約情報やサービス名などを個別に権限設定することで、より強固なアクセス制御を実施することが可能です。 権限管理機能の操作手順 権限管理機能の操作手順は以下の通りです。 ユーザ・グループを作成する 権限を作成する グループと権限を紐づける なお、上記操作は「権限管理(IAM)API」を使います。詳細は API Docs をご確認ください。 実際に権限管理機能を使ってみる それでは実際に権限管理機能を使ってみましょう。 今回はBusiness Process APIに対して様々な権限管理を設定してみます。 Business Process APIとは、NTT Com各種サービスのビジネスプロセスに関する情報提供や、操作を可能とするAPIです。契約情報API、サービスオーダーAPI、チケットAPI、メンテナンスAPIがあります。 契約情報APIにアクセスできるようにする まずはBusiness Process APIの一つである契約情報APIにアクセスできるユーザを作成してみます。 手順は以下の通りです。 準備 権限管理機能を利用するには、ビジネスポータルからお申込頂くデベロッパポータルのアカウント（以降、権限管理者）が必要です。もしお持ちでない方は こちら からお申込みください。 API利用のための認証情報の取得 以下の通り権限管理者でOAuth APIにアクセスし、accessTokenを取得します。今回はhttpieというツールを使ってAPIにアクセスしています。 リクエスト 権限管理者のclientIdとclientSecretを入力してaccessTokenを取得します。clientIdとclientSecretはデベロッパポータルから確認できます。 http -v POST https://api.ntt.com/v1/oauth/accesstokens grantType=client_credentials clientId=[権限管理者のConsumerKey] clientSecret=[権限管理者のConsumerSecret] レスポンス 以下のようなレスポンスが返ってきますので、accessTokenをメモしておきます。 { "accessToken": "[権限管理者のaccessToken]", "expiresIn": "86399", "issuedAt": "1441957092928", "scope": "READ WRITE", "tokenType": "BearerToken" } ユーザを作成する 契約情報APIにアクセスできるユーザを、権限管理APIを使って作成します。この操作も権限管理者で実施してください。 ユーザ(userA@example.com)の作成 リクエスト http -v POST https://api.ntt.com/v1/iam/users "Authorization: Bearer [権限管理者のaccessToken]" \ mail=userA@example.com \ portalUse=1 \ # デベロッパポータルの利用を許可する場合は"1"を入力 password=****** \ distributorFlag=0 レスポンス 正常にユーザが作成されると、以下のようなレスポンスが返ります。 { "users": [ { "consumerKey": "[userAのConsumerKey]", "consumerSecret": "[userAのConsumerSecret]", "distributorFlag": 0, "mail": "userA@example.com", "portalUse": 1, "uuid": "[userAのuuid]" } ] } 以上でユーザ作成は完了です グループを作成する 次にユーザが所属するグループを作成します。この操作も管理者権限で実施してください。 グループ（groupA）の作成 リクエスト http -v POST https://api.ntt.com/v1/iam/groups "Authorization: Bearer [権限管理者のaccessToken]" \ groupName=groupA レスポンス { "groups": [ { "groupName": "groupA", "roles": [], "uuid": "[groupAのuuid]" } ] } ユーザをグループに紐づける 作成が終わったら、ユーザをグループに紐付けます。複数のユーザを同じグループに紐づけることもできます。 リクエスト groupIdとuserIdは上記手順で取得したuuidを指定してください。 http -v PUT https://api.ntt.com/v1/iam/groups/[groupAのuuid]/users/[userAのuuid] "Authorization: Bearer[権限管理者のaccessToken]" レスポンス { "groups": [ { "users": [ { "userId": "[userAのuuid]" } ], "uuid": "[groupAのuuid]" } ] } 権限を作成する いよいよ権限の作成です。 今回はBusiness Process APIで提供されるAPIのうち、契約情報APIだけアクセスできる権限(roleA)を作成します。 なお権限付与はホワイトリスト形式で指定します。デフォルトでALL DENYになっているので、リソースに対して許可したい値を権限に追加していく形になります。全て許可したい場合はワイルドカードを指定してください。 なお、本操作も権限管理者で実施してください。 リクエスト http -v POST https://api.ntt.com/v1/iam/roles "Authorization: Bearer [権限管理者のaccessToken]" \ resources:='[basePath:=/v1/business-process, ipAddress:=*, path:=/contracts, verb:=*, "ipAddress": "*"]'\ 　　　roleName:=roleA レスポンス { "roles": [ { "resources": [ { "basePath": "/v1/business-process", "ipAddress": "*", "path": "/contracts", "verb": "*" } ], "roleName": "roleA", "uuid": "[roleAのuuid]" } ] } グループと権限を紐づける 最後にグループと権限を紐付けます。この設定によってユーザは契約情報APIにアクセスできるようになります。 リクエスト http -v PUT https://api.ntt.com/v1/iam/groups/[groupAのuuid]/roles/[roleAのuuid] "Authorization: Bearer[権限管理者のaccessToken]" 以上で設定完了です。ここまで約５分！ 契約情報APIにアクセスしてみる それでは作成したユーザで契約情報APIにアクセスしてみます。 ユーザでOAuth認証を行う リクエスト ここからは作成したユーザでアクセスしてください。 http -v POST https://api.ntt.com/v1/oauth/accesstokens grantType=client_credentials clientId=[userAのConsumerKey] clientSecret=[userAのConsumerSecret] レスポンス { "accessToken": "[userAのACCESS_TOKEN]", "expiresIn": "86399", "issuedAt": "1441869735683", "scope": "READ WRITE", "tokenType": "BearerToken" } 契約情報を参照してみる リクエスト（ネットワークサービス"UNO"の例） http -v GET https://api.ntt.com/v1/business-process/contracts?serviceName=uno" "Authorization: Bearer [userAのACCESS_TOKEN]" レスポンス { "items": [ { "accessLineSet": , "accountId": *********, "cRef": *********, "contractId": "N********", "distinguishName": *********, "internalContractId": *********, "mainBack": *********, "mainBackGroup": *********, "optionType": *********, "serviceName": "*********", "serviceStatus": *********, "site": *********, "vpnGroupId": "V*******" }, { "accessLineSet": *********, 以下略 同様に他のサービスオーダーを確認したいときは、contracts?serviceName=****に確認したいサービス名を入力して参照してください。 特定サービスの契約情報だけ参照できるようにする 上に書いた手順で、契約情報APIにアクセスし新規契約情報を登録したり参照したりすることができるユーザを作成できました。 しかしながら実際の業務では、特定のサービスに関する契約情報だけを参照させたいケースや、参照はできるが更新や削除はできないようにしたいケースなどがあると思います。 このようなケースにも柔軟に対応できることが、今回の権限管理機能の特徴でもあります。 そこで次は、特定サービス(UNO)の契約情報だけ参照できる（更新や削除はできない）ように権限を変更してみたいと思います。 権限（ロール）を変更する 先ほど作成した権限(roleA)を以下の通り変更します。 serviceNameに、unoを指定 verbをGET(参照)のみに変更 リクエスト http -v PUT https://api.ntt.com/v1/iam/roles/[roleAのuuid] "Authorization: Bearer [権限管理者のACCESS_TOKEN]" roleName=roleA resources:='[{"basePath":"/v1/business-process","path":"/contracts", "serviceName":"uno", "verb":"GET", "ipAddress":"*"}]' レスポンス { "roles": [ { "resources": [ { "basePath": "/v1/business-process", "ipAddress": "*", "path": "/contracts", "serviceName": "uno", "verb": "GET" } ], "roleName": "roleA", "uuid": "[roleAのuuid]" } ] } UNO以外の契約情報APIにアクセスしてみる レスポンス { "errorCode": "403", "errorMessage": "You do not have permission to the API." } このように、パーミッションエラーが表示されアクセスできないように制御できます。 契約情報API以外のAPIへもアクセスできるようにする 次に、契約情報以外のAPIへもアクセスできるように設定してみます。 追加するAPIはサービスオーダーAPIです。 今回は契約情報APIとサービスオーダーAPIにアクセスできるようにする(=or条件)ため、権限(roleA)に新たなresourcesを追加するように設定します。 グループと権限の関係性については API Docs に詳細を記載してありますのでご確認ください。 リクエスト http -v PUT https://api.ntt.com/v1/iam/roles/[roleAのuuid] "Authorization: Bearer [権限管理者のaccessToken]" roleName=roleA resources:='[{"basePath":"/v1/business-process","path":"/contracts", "serviceName":"uno","verb":"GET"}, {"basePath":"/v1/business-process","path":"/service-orders", "serviceName":"*", "verb":"*"}]' レスポンス { "roles": [ { "resources": [ { "basePath": "/v1/business-process", "path": "/contracts", "serviceName": "uno", "verb": "GET" }, { "basePath": "/v1/business-process", "path": "/service-orders", "serviceName": "*", "verb": "*" } ], "roleName": "roleA", "uuid": "[roleAのuuid]" } ] } サービスオーダーAPIへアクセスする それでは追加したサービスオーダーAPIへアクセスしてみます。 リクエスト http -v GET https://api.ntt.com/v1/business-process/service-orders?serviceName=uno" "Authorization: Bearer [userAのACCESS_TOKEN]" レスポンス { "items": [ { 　"contractId":"N********", 　"serviceName":"********", 　"orderType":1, 　"offerPlanDate":"********", 　"orderStatus":1 　"orderRequestNum":"************" } ] "resultCount":1 } このようにサービスオーダーAPIにもアクセスできるようになりました。 特定の場所からだけ契約情報APIにアクセスできるようにする 利用するユーザによってアクセスできるリソースを限定することができましたが、現在の設定ではどこからでも契約情報APIやサービスオーダーAPIにアクセスできてしまいます。外出先や自宅などからはリソースにアクセスさせたくないケースもあるかと思います。 次は社内など特定の場所からだけ契約情報APIにアクセスできるように設定してみます。 新たな権限(roleB)を作成する リクエスト http -v POST https://api.ntt.com/v1/iam/roles "Authorization: Bearer [権限管理者のaccessToken]" roleName=roleB resources:='[{"ipAddress":"192.168.1.100"}]' レスポンス { "roles": [ { "resources": [ { "ipAddress": "192.168.1.100" } ], "roleName": "roleB", "uuid": "[roleBのuuid]" } ] } 権限(roleB)をグループに紐付ける リクエスト http -v PUT https://api.ntt.com/v1/iam/groups/[groupAのuuid]/roles/[roleBのuuid] "Authorization: Bearer [権限管理者のaccessToken]" レスポンス { "groups": [ { "groupName": "groupA", "roles": [ { "roleId": "[roleAのuuid]" }, { "roleId": "[roleBのuuid]" } ], "uuid": "[groupAのuuid]" } ] } 許可されていない場所からAPIにアクセスすると、パーミッションエラーが表示されます。 { "errorCode": "403", "errorMessage": "You do not have permission to the API." } 今回はBusiness Process APIに対して権限設定を実施してみました。 次回以降、弊社のクラウドサービスやネットワークサービスにおける権限管理の設定例を随時紹介していく予定です。お楽しみに。