Swaggerでドキュメントを記述していて詰まるところが幾つかあります。今回はその注意点を紹介します。 リクエストパラメータは配列、レスポンスはオブジェクト 最も戸惑うのがこの点です。リクエストパラメータは次のように定義します。 "parameters": [ { "name": "serviceId", "type": "string", "in": "query", "description": "サービスID", "required": true }, { "name": "accessToken", "type": "string", "in": "query", "description": "アクセストークン", "required": true } ], 各リクエストパラメータを配列で定義します。inはパラメータをセットする場所で、 query : クエリストリング formData : フォーム header : HTTPヘッダー path : パス body : ボディー が利用できます。 対してレスポンスは次のようになります。 "responses": { "200": { "description": "HTTP経由でアクセスするファイル情報", "schema": { "type": "object", "properties": { "result": { "type": "number", "description": "エラーがなければ0" }, "fileData": { "type": "string", "description": "ファイルのデータ" }, "size": { "type": "number", "description": "ファイルサイズ" }, "version": { "type": "string", "description": "バージョン番号" } } } } } schemaというキー以下に定義していきます。typeはデータ型で、 object array number string integer boolean file などが使えます。 レスポンスが配列の場合の書き方 レスポンスが配列の場合、itemsというプロパティにその内容を記述していきます。これは固定のキーなので注意が必要です。 responses: 200: description: "" schema: type: "object" properties: artists: type: "object" properties: href: type: "string" description: "" items: type: "array" items: type: "object" properties: external_urls: type: "object" properties: spotify: type: "string" description: "" 配列がオブジェクトを返す場合であってもschemaというキーは不要です。これは最初だけにしか使われないようです。オブジェクトの場合はpropertiesというキーに対してデータを定義していきます。 Definitionsの使い分け リクエストやレスポンスの形をDefinitionsとして定義することができます。これは全部で3つ用意されています。 Schema Definitions Parameters Definitions Response Definitions Schemaはリクエスト、レスポンスで共用できます。他はそれぞれリクエスト、レスポンスのみで利用できます。目的に合わせて定義する場所を変更できますが、多くのRESful APIの場合リクエストとレスポンスの形式を合わせるので、結果的にSchema Definitionsしか使わないというのが管理上も楽ではないかと思います。 Definitionsは継承できない 意外と面倒なのが一定の形を定義しつつ、必要に応じてフィールドを追加したいという要望です。しかしDefinitionsを継承してフィールドを追加することはできません。逆説的になりますが、Swagger.jsonを書きやすい形で文書を定義すると綺麗なAPI設計につながるかも知れません。 Markdownが使える、使えない部分がある これはSwaggerというよりもSwagger UIの問題なのですが、項目によってはMarkdown記法が使えたり使えなかったりします。詳しくは Swaggerでのapi開発よもやま話 の34ページ目を参照してください。 Swaggerはきちんとした仕様に基づいて作られてきた訳ではありません。そのため、現在はOpenAPI Initiativeによって定義がまとめられようとしています。仕様が定まれば表示上のツール、エディタの動作についても統一感が生まれて使い勝手が良くなることでしょう。

Swaggerフォーマット（Open API Specification）でAPIドキュメントを作成するとどんなメリットがあるのか紹介します。一つのフォーマットから多彩な展開ができるようになっていると、開発工数を低減や品質向上に大きく寄与するはずです。 ドキュメント Swaggerを使ってドキュメントを生成するのは基本と言えます。多くの方がSwaggerをAPIドキュメントのために使っているのではないでしょうか。Swagger UIのようなツールを使うと、その場でAPIをコールできる機能が付いたドキュメントが生成できます。 現状の問題はあまりフレキシブルな機能をもったドキュメント生成ツールが多くないことでしょう。Swagger UIにもテーマはありますが、まだあまり多くありません。そのため、Swagger UI製のドキュメントはどれも似た雰囲気になってしまっています。 コード Swagger UIを使ったコード生成ツールとしてSwagger Editorが挙げられます。クライアント/サーバサイドのコードを生成可能で、多くのプログラミング言語に対応しています。自動生成なので使い勝手がとても良いコードではないこともありますが、それをベースにラッピングして使いやすいSDKに仕上げることもできるでしょう。 さらにかつてのWSDLのようにスケルトンコードの生成機能をもったライブラリもあります。そうしたツールを使うことで、APIファーストであったりAPIの追加に伴うライブラリメンテナンスコストの削減が実現できるようになります。 モックサーバ SwaggerのベースであるJSON/YAMLファイルはサーバの動作を規定したファイルになります。そこで開発用のモックアップサーバとして使えるソフトウェアがあります。あくまでもモックではありますが、クライアントアプリケーションの開発に役立ちます。 サーバとクライアントサイドの開発が分かれている場合、APIが整っていない状態ではクライアント側の開発が行えずに遅延してしまうことが多々あります。ドキュメントを先に整備することでクライアント側の開発がスムーズになるでしょう。 バリデーション JSON SchemaのようにSwaggerを使ってバリデーションを行うことが可能です。バリデーションは複数パターン考えられます。 クライアントサイドのリクエスト検証 クライアントサイドでデータを送信する前に検証します。これによりUXを向上させたり、サーバ側のアクセスを減らすことができます。さらにJavaScriptによるバリデーションのコードを書かなくて良くなるのでコードの重複、メンテナンスコストを軽減できます。 サーバサイドのリクエスト検証 クライアント側と同様にサーバ側も送られてきたデータの検証ができるようになります。これが大多数の目的になるでしょう。サーバ側でも入力値の検証を行うのは面倒なので、Swagger内で定義されている内容を元に検証できると手軽です。 クライアントサイドのレスポンス検証 さらにクライアントサイドではサーバから送られてきたレスポンスについて検証を行うこともできます。多くの場合、サーバレスポンスは無条件に信用してしまいがちですが、データが欠損してたり仕様と異なることはよくあります。 テストケース Swaggerを使ったテストとしてはAPIサーバの実装が正しく行われているかどうかの検証が大きな目的になるでしょう。これはドキュメント/テストファーストで実装した時に役立ちます。また、定期的に実行することで実装が変わっていないことの検証も可能です。 テストケースを生成するソフトウェアの場合、多くは正常系のテストになるようです。そのため、異常系のテストを行う際には多少のメンテナンスが必要になるので注意してください。 Swaggerのドキュメントを整備することで多くの利用が可能になります。APIドキュメントファーストとも言える駆動型開発で効率的な開発を行ってください。

前回はxTechについて紹介しましたが、今回は主なxTechの種類を紹介します。自分に近い市場があるか、ぜひご覧ください。 なお、各名称については確定していないところもあり、呼び方が異なる場合があります。 FinTech 言わずと知れた金融×テクノロジーです。ここ1、2年ほど銀行を中心に盛り上がってきています。APIの開示には個別の契約が必要な場合が多く、FinTech参加企業によるエコノミーが構築されてきています。 RetailTech 物流、倉庫などを主体とした流通に関する分野です。物流業界は効率的な配送や再配達システムなど、元々高度なテクノロジーが使われています。さらにそのビッグデータを活用することで新しいサービスが生まれる可能性があるでしょう。 MarTech マーケティング×テクノロジーです。特に強いのがSalesforceで、CRMを軸に独自のAPIエコノミー、パートナーシップが構築されています。 他にもEメールマーケティングであったり、オートメーション、効果測定などの分野においてテクノロジー利用が広がっています。 EdTech 教育分野になります。元々かなりインターネット利用が遅れている分野ではありますが、タブレットによる電子教科書など徐々に進められています。 MedTech 医療分野です。法律的な規制が厳しい分野ではありますが、ここ数年技術革新が進んでいます。遠隔地医療であったり、A.Iを使った簡易診断など医療が十分に提供されていない地域において注目が集まっています。 HRTech 人事×テクノロジーの分野になります。教育や医療と同じく、人が積極的に関わっていく分野ではアナログが作業がまだまだ多くなっています。人材活用などにおいてデータをもとに数値化する動きが高まっています。 LegalTech 法律分野になります。グローバルなビジネスが増えていく中で、各国の法律を遵守しつつも高速な対応が求められるようになっています。また、仕業や企業法務などをクラウド化する上でも注目されています。 HealthTech 健康分野は常に注目の高い分野です。センサーを使って個人の状態をモニタリングし、変化するステータスに合わせて適切なアドバイスを行うといったことが考えられます。 AgriTech 農業分野もITテクノロジーがなかなか普及していない分野でしたが、IoTのセンサーと組み合わせた活用によって、これまで感覚でしか分からなかった情報が可視化されたり、省力化が実現しています。 FoodTech 衣食住の一つでもある食に対する取り組みです。宅配のようなものであったり、完全栄養食と呼ばれる食べ物の開発など多彩な展開が行われています。 SportTech スポーツにおいてはバンドをつけて個人の活動量を測定したり、個人の活動をシェアするといった利用が行われています。プロにおいてもパフォーマンスを数値化する上でテクノロジーが活用されています。 FashTech ファッション分野においては新素材の開発やセンサーをつけた洋服、感情によって色が変化する素材など未来的な試みが数多く実施されています。 GovTech 政府関係のテクノロジー活用です。主にオープンデータ系の活動で使われます。また、政府が出しているソフトウェアを改善、啓蒙するような活動も行われています。 AdTech 言わずと知れた広告系のテクノロジー活用です。広告分野はリスティング広告の登場以降、一気にテクノロジー主体になっています。 RETech 不動産×テクノロジーという分野です。住宅ローン、中古売買、賃貸などを自動化します。金融系と密着したサービス展開が多いようです。 他にもxTech分野は増えていくと思われます。旧態依然とした市場に対してテクノロジーがどう変革を起こせるか、xTechは楽しみな動きと言えるでしょう。

私たち、APIチームが提唱していこうとしているのがxTech（エクステック）と言うキーワードです。今回はその概要を紹介します。 xTechとは？ 最近話題になっているFinTechというキーワードがあります。Finance（金融）×Technology（技術）という二つのキーワードを合わせた造語です。同様に、Agriculture（農業）×TechnologyのAgriTech（アグリテック）、Education（教育）×TechnologyのEdTech（エドテック）、Advertisement（広告）×TechnologyのAdTech（アドテック）などがよく知られています。そんな○○×Techという名称を総称してxTech（エクステック）と呼んでいます。 xTechとAPIの関係とは？ ではxTechにおいてAPIはどう使われているのでしょうか。ほぼすべての施策において、技術的基盤になっているのがAPIと言えます。企業間連携はもちろん、複数の企業が提供するデータを合わせたり、自社のサービスにコンテンツを付与するといった場合もAPIを使っています。そういった作業が自動化されなければ、コストが増大してしまって付加価値としての意味がなくなってしまうでしょう。 あえてAPIという単語をあげるまでもなく、xTechにおいてAPIの存在は当たり前のものとして浸透しています。 なぜ今xTechなのか FinTech、Agritech、EdTechなど、なぜ多くのxTechキーワードが生み出されているのでしょうか。それはテクノロジーの発展と、スマートフォンの普及によってインターネットが常時存在する生活が当たり前になっていることが一つのポイントになってくると考えられます。また、IoTも合わせてスマートフォンとともにセンサーデバイスが数多く存在します。私たちが日々生活するだけで、そうしたスマートフォンやWebブラウザの操作、センサーデバイスから刻々とデータが生成されるようになっていると言えます。 そうして集まったデータを旧来の市場にぶつけることで新しい付加価値を生み出せるようになってきたと言えるでしょう。AdTechのように元々テクノロジー主体だった分野はもちろん、農業や教育、医療などインターネット技術とは縁遠かった分野においても活かせるデバイス、センサーが登場してきています。 私たちは何をすべきか xTechへの取り組みは主に2つ考えられます。一つはテクノロジー分野にいる人たちです。テクノロジー分野にいる人たちは他の市場へ働きかけることでAPI開発、他企業との連携など大きなチャンスを掴める可能性があります。ただし他の市場においてはテクノロジーへの投資金額が大きくないこともあり、スクラッチで開発するよりもAPIマネージメントサービスを使った素早い実装、スモールスタートな実証実験が求められるでしょう。また、他市場への知識が圧倒的に不足しているため、まずその市場の学習と理解が必須になります。 もう一面は農業、教育、医療などの分野に携わっている企業です。こうした企業では従来のワークフローでビジネスが回ってしまっていることが多く、それをさらに改善、拡大したい、新しい収益構造を生み出したいという強い欲求が必要になります。ただしテクノロジーへの知識が不足しているため、まず地場のシステムインテグレータなどに相談してみるのが良いでしょう。その際には企業の大小ではなく、先進的取り組みを積極的に行っているか、xTechへの知識があるかといった点がポイントになるでしょう。 xTechは去年くらいからの動きになります。まだまだはじまったばかりで、今年や来年は新しいサービスや事例が登場してくることでしょう。ぜひこの動きに追従し、取り組んでみてください。

今回はAPIのバージョン管理について主なパターンと、既存のソフトウェアで使われるバージョン管理との相違点について紹介します。 パス もっともオーソドックスな方法と言えます。多くの場合、次のようになります。 /v1/users またはバージョン番号を日付で行っているケースもあります。 /2016-06-01/users バージョン番号を持たせるケースの場合、何をもってv2にするかが問題になります。日付の場合、リリースしたタイミング（その日付）を使うので数字の付け方に悩むことはないでしょう。 ただし、これらの方法の場合、 何をもってバージョンを上げるか という問題が常に付きまといます。既存の修正なのか、バージョンアップなのかの区別が判断しづらいということです。できればリリース前にバージョンの付け方をルール化しておくのがいいでしょう。 また、v2を作った場合にすべてのAPIがインタフェースを変える訳ではないという問題があります。usersは変えたとしても、productsやその他のインタフェースはそのままで良いというケースがほとんどでしょう。そうした時に、あるAPIは常に古い日付であったり、逆に更新されていないけれどもバージョンが上がってしまうAPIが出ることになります。 HTTPヘッダー バージョンをHTTPヘッダーに含めるケースがあります。このメリットとしては、パスのように アクセス先を変えないで済む ということです。エンドポイントはAPIのバージョンが上がったとしても変わりません。利用者としては常に同じURLで使えるというのはメリットがあります。 デメリットとしては多くの場合、HTTPアクセス部分は共通化して作られるため、usersはv2、productsはv1といった具合に切り替えるのは簡単ではないということです。特にHTTPヘッダーのような情報は共通化した上で、v1またはv2という文字列で固定されてしまっている可能性があります。 SDKやライブラリです隠蔽する方法も考えられますが、それでもバージョンを指定してもらうというのは余計な手間を増やしてしまうためあまり良いと方法とは言えないでしょう。 クエリー クエリー文字列の中でバージョンを指定する方法もあります。こちらはHTTPヘッダーと同じでエンドポイントは常に同じです。そしてURIのクエリーの中でバージョンを指定します。HTTPヘッダーよりは変えやすい印象です。 この場合、バージョンを固定しておけば返ってくる情報は常に同じという安心感があります。パスで指定するケースに比べて、管理単位が細くなる印象です。 // パスでの指定 /v1/users /v1/products /v2/users // v1とは別なレスポンス /v2/products // v1と同じレスポンス // クエリーでの指定 /users?v=1 /users?v=2 /products?v=1 クエリーでの指定の場合、v=2は存在しないことになります。開発者としては新しいデータ取得法を使いたい場合はv=2を指定し、そうでない場合はv=1を指定することになります。 デメリットとしては共通したアクセスになるので、クエリーでの指定を見てレスポンスを返す分、ソースコードの分岐が増えてしまいます。徐々にソースコードが汚くなるかも知れません。 case params[:v] when '1' // バージョン1を指定した場合 when '2' // バージョン2を指定した場合 end もちろん最初からバージョンアップする前提で作られている場合は綺麗に設計もできるのですが、多くの場合バージョン番号は用意していても使うための仕組みはないケースが殆どです。 一般的バージョン管理との相違 パスにバージョン情報を入れた場合、印象としてはSubversionのような全体でバージョン番号を持ったバージョン管理に近い印象になります。もちろん、更新されていない /v2/productsに対してアクセスがあったら/v1/productsを呼び出すといった形にできますが、利用者としては v1 と v2 で何が違うのかと疑問に思ってしまうことでしょう。ドキュメントにその説明を載せるのも面倒です。 かつてあったCVSの場合、バージョン管理はファイル単位になります。クエリを使った方法はこれに近いものになるでしょう。アクセス先単位でバージョン番号を指定するのはあまり筋が良いとは思いませんが、現実的かも知れません。この場合、アクセス先単位でドキュメントに v1、v2の相違について掲載できるようになります。 Gitのような分散型バージョン管理の考え方をAPIのバージョン管理に適用した場合はどうなるでしょうか。これは2つの考え方ができます。 タグを使った全体の制御 まず大きなリリース単位によってタグを使います。このタグはパスに含めるのが良いでしょう。v1、v2相当になります。 アクセス先単位での細かい指定 さらに細かく動作を指定したい場合はクエリ文字列を使って設定できるようにします。これは次のタグに至るまでの細かいバージョン番号と言えます。基本的にはタグを使ったものだけで十分でしょう。 APIのバージョン管理はあまりうまくいっていないケースが多い印象があります。どのタイミングでバージョンを上げるか、後方互換性をどう維持するか、修正と機能追加の違いは何かといった具合です。 これらは既存のソフトウェアのバージョン管理が参考になると言えます。メジャー、マイナーアップデートなどの考え方、APIの開発計画に合わせてバージョン更新を考えていくのが良いでしょう。多くの場合、一度目のバージョンアップを躊躇してしまうためにずっと同じバージョン番号で更新を重ねてしまうようです。最初のバージョンアップは事前の計画に沿って進めていくのが良いでしょう。

Swaggerはオープンソース・ソフトウェア、オープンなフォーマットと言うこともあり、関連するライブラリが幾つか存在します。OpenAPI Initiativeが設立されたこともあり、業界標準となっていけばさらに登場してくるのではないでしょうか。 今回はそんなSwaggerによる開発を補助するソフトウェアを紹介します。 Swagger2Markup/swagger2markup SwaggerファイルをベースにMarkdownファイルを生成するソフトウェアです。若干癖のあるツールですが、MarkdownファイルであればPDFをはじめとして他のドキュメントフォーマットにも展開しやすくなります。 Markdownフォーマットは他の多くのドキュメントシステムでも使われていますので、そういったシステム向けにドキュメントをコンバートする際にも便利です。 BigstickCarpet/swagger-server: Get your REST API up-and-running FAST with Swagger and Express Swaggerファイルを使ってRESTfulなモックサーバを立てるシステムです。本番環境下ですべてのサービスが揃っていない状態でもクライアント管理がはじめられるようになります。 また、クラウド系サービスにおいてSwaggerファイルを提供することで開発者の環境においてローカルで動作するモックサーバを提供できるようになります。 Swagger UI – Swagger Swagger UIはSwaggerファイルをHTMLで表示するシステムです。HTML上からCRUD操作を実際に行えるのが特徴です。ただしOAuth2トークンなどが必要であったり、認証などを要する場合は作り込みが発生します。 SwaggerファイルをHTMLとして表示したい時にはこのSwagger UIが最も多く使われるようです。 Swagger Editor – Swagger Swaggerファイルの作成、編集を行うのがSwagger Editorです。入力内容の検証ツールも組み込まれているので、ミスしたとしても改善しやすいはずです。ツリー構造の折りたたみ機能もあり、大きなAPIドキュメントでも効率的に編集できます。 Swaggerのフォーマットに精通していないと、テキストエディタで書いた後に検証すると多数のエラーが出るはずです。最初からSwagger Editorを使うことで手戻りを減らしましょう。 Swagger Codegen – Swagger Swaggerでは多数のプログラミング言語に対応したソーコード（スケルトンコード）が生成できます。クライアント/サーバサイドの入力値検証であったり、API利用を簡便化します。 言語によってはソースコードのレベルが高くありませんが、生成されたコードをラッピングして使っても良いでしょう。ドキュメントさえメンテナンスすればライブラリが更新されて最新の状態を保てるというのが理想です。 ReDoc Swagger UIとは別なドキュメントジェネレータです。データ構造が縦に表示されるのが特徴となっています。今の時点ではSwaggerのファイルを読み込んで動的にコンテンツを生成します。今後の予定としてSEO対策のために静的ファイル生成に対応するようです。 画面構成は3ペインで、一番右側にコードサンプルが表示できます。 moongift/cURLtoSwagger: Convert from cURL command to YAML format. Compatible with Swagger. 筆者が作っているツールがcURLtoSwaggerです。cURLコマンドとそのレスポンスを使ってSwagger用のドキュメントを生成します。cURLコマンドはGoogle Chromeの開発者ツールで取得できます。 Swaggerはサービス提供側が記述する場合もあれば、すでにできあがっているAPIからドキュメントだけ書き起こす場合もあるでしょう。cURLtoSwaggerは後者向けのツールになります。 Swagger（OpenAPI Specification）に関連したツールは今後増えていくと予想されます。そうすることでSwaggerのエコシステムはさらに広がっていくことでしょう。API/ドキュメントファーストの開発においてSwaggerは見逃せない存在になるはずです。

JSON has been increasingly adopted as a Web API format. While JSON can be handled easily in light description languages, the trouble it has with assuring data content is viewed as problematic. For this reason, JSON Schema, which defines the structure of JSON, has attracted attention. By providing types and meta-information to JSON data, rules for formatting are added. JSON Schema is currently being developed as a specification. You can check the details at JSON Schema and Hyper-Schema . We’d like to think about what possibilities adopting JSON Schema can bring. 1. Validation The primary one that comes to mind is validation. This can be done for both clients and servers. JSON Schema enables you to verify data before sending and automatically validate data you obtain. If the verification results produce errors, you should probably return them as they are. As usage of data structures and types is assured after verification, you can feel secure when writing code. 2. Create Libraries that Handle Data This is similar to how "Web Service" often automatically generate code from a schema like WSDL. It will automatically generate skeleton code if it’s for Java or .NET, and it will automatically create methods for script languages such as Ruby, PHP, and Python. JSON is often handled with hash and associative array after parsing. However, by generating code in advance, you’ll be able to use it as easy-to-handle data. 3. Generate Documents In addition, since JSON Schema explains parameters and also handles descriptions for data structures and URLs, it can be used for generating API documents, too. Although consistency must be maintained due to separation from the actual code, you can maintain the latest state by combining JSON with testing structures, which will be mentioned later on this page. As there are many developers who refer to API documents, such output should motivate you to properly maintain JSON Schema. 4. Dummy Server JSON Schema can be used as a base for library test servers that handle Web APIs. Although the logic parts of the server cannot be assured, having a dummy server makes local development and operation in a test environment easy. However, while you can check requirements and types of input values on dummy servers, it doesn’t allow you to check logic, such as token validity. Note that it’s better to use it as an auxiliary tool during development. 5. Automating Test Also, JSON Schema can be used for operating tests for a Web API itself. Post the pre-defined values, and you can verify whether the expected results will be produced. Systems that previously used Web APIs may suddenly stop working, for instance, when new required fields are added to extend the Web API. Also, in such circumstances, it is important for JSON Schema to manage versions and check whether it’s continuously operating with all versions. After software that uses a Web API is complete, the software often enters an automatic operation phase. In order to ensure results even in such circumstances, JSON Schema can be useful. 6, Error Check During Development With IDEs and such, adopting JSON Schema enables you to display advance warnings. The JSON structure has low readability when kept in text form, and it is often read incorrectly. JSON Schema could be useful to prevent these mistakes. Although JSON Schema has several merits, because it was originally developed to stay away from the complexity and nuisances of WSDL and such, it has not been widely adopted. However, it will turn into an important element, as Web APIs will be used more and more often at the enterprise companies. Rather than just being something that you should do, I believe JSON Schema will be used more if it can improve development productivity and reduce burden, for example, by automatically creating documents using JSON Schema.

When you will mash up APIs and create a new service, you have to first find an API providing the data that you need. In this installment, I summarize services offering directories of APIs. PublicAPIs As of this writing, this indexing service lets you search 5,330 APIs. You can find out APIs, and also register new APIs in the system. PublicAPIs | Directory of public APIs for web and mobile API For That APIs are indexed across approximately twenty categories that include social networks, finance, and more. There are close to three hundred categories. API For That | An API Directory Zapier The service functions like an enterprise version of IFTTT. Users link two services to trigger actions. The Explore menu lets you access a wide range of APIs (limited to those supporting Zapier). The best apps. Better together. - Zapier ProgrammableWeb This site provides API directory information and news. Over 13,000 APIs are offered. While there are few Japanese APIs, if you plan to search APIs worldwide, this site is the best. ProgrammableWeb - APIs, Mashups and the Web as Platform Mashup Awards You are seeking a Japanese API, check the Mashup Awards API list page for a comprehensive list. You will also find overseas APIs, with close to 250 APIs indexed. APIリスト | MA【エム・エー】 by Mashup Awards When you want to poll GPS information like weather or hotel information, you will get better fidelity by using an API from the target country. At the same time, linking two APIs may yield unexpected potential and results. Settling on what you want to build before searching for APIs is one technique, but you could also go in reverse, looking at these lists and getting inspiration from what you find.

What are the challenges and advantages of enterprise API utilization? In order to get a grasp of the situation, we conducted an interview with Mr. Kato, an API gateway developer. The interviewer is Nakatsugawa from MOONGIFT. What are the API gateways you planned from 3 years back? With 10 years having passed since the popularization of Web APIs (hereinafter referred to as “APIs”), there has been a movement in these past few years among businesses to increase the competitiveness and utilization rates of services by making APIs open. We at NTT Communications have also API-tized our services and are trying to promote their use. Rather than creating a separate API for each service, API gateways refer to attempts to provide an easy-to-use API that standardizes them and unifies management. A number of similar services have become available in these past one or two years. We planned it about 3 years ago when we carried out a technical verification and launched the project, and it became an officially released service from April this year. The actual development period was only about 6 months as we had made some progress beforehand on technical verification. API management services already starting overseas Carriers such as AT&T and Verizon are already starting. There are three primary reasons why carriers are making progress. They have a wide range of services Customer loyalty is improved by providing these services through a common interface It serves as a technical cushion for a wide range of sectors As an example of problems that can arise when there is no API management mechanism – although this was not APIs – there was a period at NTT Communications during which each department developed smartphone applications freely without any company standards. As a result, there was no sense of uniformity among interfaces and overall quality, which was confusing for users. In order to prevent similar problems from occurring with APIs, we thought of 2 measures. API gateways API checklists API checklists define how APIs are to be develop, rather than just develop them. APIs can be made so long as you have the technical capabilities. However, how to best make them is where differences of opinion arise among the people involved. It is for this reason that we created an API checklist as a unified standard for things such as interface, security, data format, etc.. One point that we were particularly careful about was to use JSON Schema that enables automation or JSON format schema check, a lightweight format based on REST API rather than SOAP. By sticking to these guidelines, we believe that we can create APIs that our clients have no problems with. ※ Please refer to the following article for more on API checklists (Japanese articles). Things that should be kept in mind in order to design a proper API: Interface Data format Version control, synchronously or asynchronously Security API provision with regard to enterprise can be thought of as the opening up of in-house systems. As there are user limitations in conventional business systems, it is not too much of a problem even when services were temporarily suspended for things such as maintenance. However, as API-tization of these systems means they will be used for automation from outside, things such as down time and information freshness can become a problem. Taking these points into consideration, and as it needed to be system development, we felt that there was a need to change our way of thinking through a fixed framework. Public was not enough. What was the next step after that? Although many APIs have been made over the past 10 years, there are many cases in which they were simply made and abandoned. In order to prevent this, we believe there is a need for: A presentation of a mash-up example using third-party API Applications, tools, and sample codes that use API We are currently thinking of enhancing libraries and mechanisms that support such developments. One thing we often hear from developers who are trying to develop using APIs in reality is that they find it difficult to get a sense of scale. The reality is that the sense of scale varies with the application being made, therefore, we want engineers to train their senses by first writing small lines of code using APIs. Our model is that, instead of trying to tackle a large project from the start, it is best to start off small and slowly work your way up to larger projects. What is the model you aim for with API gateways? First of all, the API-tization of NTT Communications's services is only the first step. For the next step, we are thinking of API-tizing the services of our client companies and engaging in their management and operation. However, as we are now at the stage where we are promoting API-tization in regard to networks and cloud, all in all, we are still at 20%-30%. Additionally, we are also focusing on the IoT market. For example, we believe that API gateways can serve as hubs that stand between IoT devices and developers. Data, threshold values, etc. gathered from devices will be available to the public through the API. Moreover, there are also plans to introduce mechanisms that push information both ways using things such as WebHooks and WebSockets. About 2 years ago, APIs were still at a stage where developers were just starting to get a feel for it. After that, from about last year, the importance of APIs started to be acknowledged, even in the executives. We want to spread the idea that, although it takes time to add an API to an existing service, effects can be increased 2-3 fold while development costs can be kept at 1.1 to 1.2 fold by preparing “API First” from the beginning when developing a new service. That being said, enterprise API utilization still has a long way to go. To address this issue, we, as ourselves and regardless of our relation to NTT Communications, are planning Enterprise APIs Hack-Nights in order to boost enterprise API utilization and make it more exciting. We hold these events regularly so please feel free to participate!

The evolution of the cloud has brought big data and the field of machine learning, which is currently receiving a lot of attention as the next big thing. Actually, machine learning has quite an extensive history, with research beginning back in the 1950s. In this article, we’ve assembled a collection of convenient machine learning APIs for you try out. Prediction API Google’s machine learning service, the Prediction API. Their RESTful API for learning from training data, etc. allows seamless connectivity to Google’s various Cloud Platform services. The API supports Google Sheets as well—use the Prediction API directly from within your spreadsheets! This is a unique advantage that only Google can bring. Specifically, users need to install an add-on called Smart Autofill. We tried it out, and getting predictions is easy. All you need to do is select the needed cells to get your predictions. Smart Autofill Spreadsheets Add On The documentation is mostly in English, but everything is easy to read and understand. The project has only just been open sourced (in November 2015). We’ll likely see more and more information as time goes on. The pricing structure has free and paid versions. The free tier is more than enough to try things out for yourself. See below for the detailed pricing structure. The SLA guarantees 99.9% monthly uptime. See here for detailed pricing information. Documentation Quickstart Microsoft Azure Machine Learning A machine learning service for Microsoft’s Azure cloud service platform. The most impressive feature is its Machine Learning Studio graphical interface, but users can access the platform via both the GUI and API. Free users are only allowed to do staging procedures. To switch to a live operating environment and acquire endpoints, users need at least a Standard Plan (explained later) subscription. The Japanese documentation is largely complete, and both the tutorial and the GIU management information is organized in an easy-to-understand way. There’s an instructional book on sale too—the cost of learning should not be high. The pricing structure is separate from the Azure platform and divided into Free and Standard Plans. The Standard Plan is completely pay-as-you-go and starts in the ¥1000-¥2000 range. See the pricing details page for more information. The SLA states that Microsoft guarantees 99.95% availability of API transactions for the Request Response Service (RRS). Documentation Tutorial Amazon Machine Learning| AWS AWS’s analytics service, Amazon Machine Learning. The documentation is in English and is quite substantial. It is a little difficult to understand, and there are so many services that users may have trouble finding the service they need. After logging in to the console, first try to find the analytics area. At the time of this article’s writing, availability is restricted to the Eastern US and the EU (Ireland). You should get a decent idea of how the specifics work by going through the tutorial. Pricing for AWS is exceedingly difficult to understand, but data analysis and model construction fees are, at $0.42/hour, set higher than other services. For details, please refer to the data analysis and model construction fees . The AWS Amazon Machine Learning service cannot currently be used with the AWS 12 month free tier trial. We almost missed the warning message. Be careful not to miss this when using their product. Documentation Tutorial bigml “bigml” is an API service that offers cloud machine learning and predict analytics services. The GIU is easy to use, and the machine learning doesn’t come off as troublesome. Users can get started right away after logging in. There are several sample datasets prepared. Going through these should give you a general idea of how the platform works. For Web services, bigml provides a fully controllable RESTful API. The documentation is well-supported, and users should not find themselves getting lost. See the documentation here . The pricing starts at a monthly plan option for $30 or a yearly plan that, when paid together, costs $240 (calculates to $20 per month). However, be aware that this pricing can change depending on usage and data volume. indico Users are issued an API key after logging in and can use this key to start coding right away. The platform provides code samples for Python, Ruby, Java, NodeJS, PHP and R, so experienced programmers should have no problem getting started. The below demo is an sample of text sentiment analysis. It includes actual example code that for reference in your own models. The API is free for up to 10,000 calls per month. There is a fee afterwards, but the amount is on the low side. Furthermore, the system currently only supports English, but the machine learning service API is extremely easy to pick up and use. Machine learning has an image of being cumbersome and difficult to handle. However, after trying things out myself, we found that things weren’t as bad as we had thought. We were able to implement algorithms like regression analysis and Bayesian filtering without what felt like too It has become a commonplace and accepted practice for companies to leverage big data to filter data, provide recommendations, etc. The introduced services all have free tiers, so why not give them a whirl when you have the opportunity.

In this installment, I will write about precautions involved in offering an enterprise-level API. With increased use of APIs in BtoB and other enterprise contexts, taking the following points in mind is sure to help you provide a more user-friendly API. 1. Unified API specs and rules When each and every API has a varying interface and data format, the result is confusion among users, and your API will see limited use. While there is no industry standard, recent trends revolve around REST interfaces and data formats in JSON or XML. In addition, a bare minimum of the rules described below in terms of version control and parameter naming conventions should be agreed upon internally before release. 2. Privilege management Privilege management is extremely important in the element of enterprise API. Ordinarily, an API assigns one token per user or is based on the premise of use via a single application. However, in an enterprise context, multiple organizations (users) coexist. For this reason, you must assign CRUD (create, read, update, delete) privileges for each organization and user. For example, members of organization A may be allowed to create data, but they cannot update it. The systems administrator at the company must be able to freely configure these privileges based on actual use. We will be offering privilege administration functionality starting in September of last year in order to offer a more safe and flexible control of API access. Click here for information on privilege administration on the IAM API . 3. Logging While most APIs provide log data on a call level, an API in an enterprise context will need to keep logs on what data was accessed and what functions were performed, both on an API basis and a user basis. This is a must for auditing purposes, and it is critical for exploring the cause of incidents when they occur. Because APIs often span systems, they may be used in unseen ways, including sudden batch processing at night. This perforce requires logging at a fine-grained level. 4. SLA and maintenance response While an API functions automatically, this does not mean you can set it and forget it. Further, periodic maintenance will also be practiced. Therefore, the API must have an SLA and built-in responses and rules for maintenance. In the absence of such agreement, you find cases where services using an API simply return a 500 HTTP status error with no explanation. It is no surprise, then, when concerned e-mails reach the administrator. Implementing thorough error documentation allows the user to respond in the event of a problem. 5. Version control In an enterprise elements, API updates must be performed in a critical fashion, so manage version control based on a specific set of standards. Ordinarily, a version number is fixed to the API endpoint and new and old versions are distinguished in this way. There may be cases where a system is not equipped to immediately work with the latest bleeding-edge version of an API, so design the structure such that new and old versions can be concurrent, without immediately deprecating old versions. 6. Documentation There are a surprisingly large number of cases where APIs lack sufficient documentation. While the provider may consider the literature sufficient, putting oneself in the user's shoes, one finds that the information is often totally lacking. It is not enough to simply convey the information accurately -- the documentation must be neither too skimpy nor too robust, and it must be easy to use. Aim to have your documentation available online. Oftentimes, when setting up a dedicated search server, the result pales in comparison to Google and other search engines, and its usability is lacking. Further, distributing documentation in PDF or similar formats much to be desired in terms of searchability. 7. Libraries/SDKs Another point equally as important as documentation is your libraries and SDKs. You will not simply be providing an API -- you must also have libraries and SDKs corresponding to various programming languages. You can begin by providing ones tailored to the environments in which you want your users to deploy the API, and then roll out libraries and SDKs for other languages. Corporate systems are not composed of a single language, so you will need many libraries and SDKs. Taking future maintainability into mind, aim to keep libraries and SDKs thinly wrapped around the API. The point about documentation applies to libraries and SDKs, too, which should have ample literature and sample applications. 8. Sandbox Lastly, make sure to offer a demo environment for testing the API. Having to immediately update and delete data in a live environment poses too much of a risk to companies. Aim to automatically prep data that is as close to a live environment as possible; ideally, the system should copy data directly from the existing live environment. Being able to test maintenance functionality is also a plus. API-based development is not complete out of the gate. It is something that is continuously updated and added to. For this reason, sandbox environments should not be limited to 30-day trials and the like, but available persistently. When expanding use of an API to beyond one's company and offering it publicly in an attempt to foster new business, there are many considerations to make, the above notwithstanding. In particular, when opening up the stores of data accumulated at your company, a level of management commensurate with that data is needed. It is not simply enough to make the data public -- provide the API only after considering the peripheral technologies and ease of development and use by enterprise users.

It is not realistic to manually create JSON schema. It is something used by the system, there are aspects which are difficult to understand how to write, and it is bothersome to describe things such as the validation conditions. This is why JSON schema generation software and libraries are so useful. They are available for all types of programming languages, making it easy to choose the one that suits you. JSON Schema Generator JSON schema generators can be used to edit JSON schema within your web browser. In addition to over settings, it is possible to visually execute validation settings for all items individually. The result is a one-line JSON string, meaning that it can be used directly in your development. json-schema-generator This software is developed by Node.js library defines the JSON format in a highly legible way. Converting it with the JSON schema generator command will turn it into a JSON schema. Doing things in this way is significantly less work than manually constructing a valid JSON schema. perenecabuto/json_schema_generator The Python library defines, for all items, the type and whether or not input is required. Rather than using the generated result as-is it appears that it would be better to use it after compiling the value range and whether or not items are required. Nijikokun/generate-schema The Node.js library, in the same way as the Python library described above, reads a JSON file and outputs a JSON schema. In addition to JSON schema it is also compatible with Mongoose schema. JSON Schema Generator This is a library that can be used with Visual Studio 2013 Update 2. Specify the JSON file and select Generate JSON Schema from the context menu. JacksonJsonSchemaGeneration - FasterXML Wiki This is a JSON schema generator which uses Jackson (a Java JSON library). Specify the Java object and then convert that property into JSON schema. This could be used when you want to change a system which is actually operating to a JSON schema. JSON Schema Editor This is available as software for Windows. The JSON can be defined visually and validation can be specified in fine detail. This appears to be very usable, with features includes drag-and-drop structure editing. json-schema-generator | RubyGems.org | your community gem host Installation makes it possible to use the json-schema-generator command. As an option it is possible to specify the schema version. solvire/php-json-schema-generator This is a PHP library. It can be installed using composer. It is not used through commands but rather is used by being embedded with the system. ae real / JSON-Schema-Generator - search.cpan.org This is a library for Perl. It is made for generating hash-based JSON schema. mcuadros/go-jsonschema-generator This is a library that can convert Go objects to JSON schema. All properties can be defined and required conditions can be described. It is necessary to describe validation separately. There seem to be two methods of generating JSON schema – one which outputs objects in various programming languages as JSON schema and one which visually creates JSON schema. It appears that libraries can be used even with systems that are already running. Note, however, that you will need to have detailed validation settings. The visual editors could be used right from when thinking about specifications.

7月22日に行われたAPI Meetup Tokyo #15はOpenAPI Specification（旧Swagger）特集でした。イベントの告知後、あっという間に満席になってしまったというほど、注目が高まっているOpenAPI Specification、今回はそのレポートになります。 1. OpenAPI Specification/Swagger概要 API Meetup運営チーム/Apigee 関谷和愛さん OAS（OpenAPI Specification）はREST API記述のフォーマットになります。IDLの一種で、APIを機械可読な形で記述して様々な自動処理につなぐことができます。ざっくりいうとWSDLのREST版です。 Swaggerは純粋に社内のツールとして作ったのがはじまりです。JSONだけじゃなくYAMLでも書けるようになったり、一つのファイルにまとめるといった機能が追加されていきました。Swagger 2.0がOAS 2.0に名前を変えたので、中身は同じものです。Swaggerというと、ツール群も含んだ名称になっていました。今後はOASといった場合は記述フォーマットを指します。 APIのエコシステムを作りやすい環境を作っていくのがOAI(OpenAPI Initiatize)になります。OASの目指すところはAPIライフサイクル全体をカバーするフレームワークであって、単なるドキュメント生成ツールではありません。例えば以下のような展開があります。 設計ツール ドキュメント テストケース モック バリデーション スケルトンコード SDK OAS3.0は直接の互換性は保たれない模様です。GitHub上で議論、開発しているので仕様策定に参加することも可能です。リリースは秋頃を予定しています。TDC（Technical Developer Community）がリードしています。 2. OpenAPI Specification を使ったスマートな API 運用 株式会社 KUFU 芹澤雅人さん 仕様書は大事だけど軽視されがちです。今回はそのケーススタディになります。 黎明期のWeb API 2000年代初頭に実装されたAPIです。実装言語はJava、レスポンスはXML、仕様書はWordとなっています。 欠点として、そもそも仕様書が運用されていませんでした。記載の抜け洩れが目立ち、実装を確認した方が早いといった状況です。仕様書がしっかりしていないと開発はもちろんコミュニケーションコストが大きくなってしまいました。さらに設計思想の不統一が起きやすくなっており、仕組みを作らないと開発者は仕様書をメンテナンスしない実例となりました。 2011年頃 言語はJavaで、SphinxをI/F仕様書にしました。 良かった点として、Sphinxを採用したことです。Sphinxはrstで記述する仕組みです。ソースコードで同じリポジトリで管理していたので、レビュー対象となるので抜け洩れしづらくなっていました。文書はHTML/PDFに変換できました。 欠点として、仕様書の運用コストが少なからずありました。また、エンドポイントを追加する時などは結構なコピペ作業がったり、エンタープライズ向けに別で仕様書を生成できませんでした。エンタープライズ企業向けに綺麗な仕様書を作ると喜ばれ、心なしか問い合わせも友好的でした。 ここでの学びとしては、仕様書とソースコードは近ければ近いほど良いということです。また、HTML以外のフォーマットでとれるといいと思います。 最近のWeb API 最近はSmartHR APIで実践しています。言語はRubyを使っています。先にWeb APIを実装して、後からSwagger Specを生成するアプローチとなっています。デザインも良いですし、運用コストも気にならないレベルまできています。 3. Swaggerを使用したモデルファーストなAPI開発のよもやま話 TIS株式会社 小西啓介さん スマホアプリ向けのAPI開発でAPI仕様をExcelで書きたくありませんでした。漏れのないフォーマットが作れませんし、APIスタブを生成したくてSwaggerにたどり着きました。 とは言え、最初はExcelなどで整理するところからはじめました。 業務機能の洗い出し リソース抽出 項目名の名寄せ、英字検討 Swaggerは項目名だけを書くようにしています。 Path Operation 必須リクエストパラメータ いきなり細かく書くのではなく、骨格が固まったら詳細記述するようにしています。 Swagger Editorについて とても使いやすいわけではありません。構文エラーを取るのは一苦労です。他のツールで作成してから貼り付けると多数のエラーが出ます。気付きづらい機能として、Ctrl + Fを2回で置換が出ます。なお、Swagger UIとの互換性はありません。 Swagger UIについて カスタマイズが必要です。例えば認証関係、バグパッチ対応、日本語化など。なお、表示されるレスポンスは加工されています。例えば、 CORSのXHRでのエラーは不明 304は200で表示 などです。また、表示されないSwaggerの情報があります。そのためSwaggerファイルも公開すべきです。後、アルファベット順で必ずソートされるのが仕様となっています。 Swagger Nodeについて フォーマットバリデーションが便利です。リクエストだけでなくレスポンスのバリデーションもしてくれます。なお、additionalProperties:falseにすると大変です。 Swagger仕様について 全体の構成が分かりづらいです。例えばリクエストとレスポンスが非対称で、リクエストは配列、レスポンスはマップで定義という違いがあります。 OpenAPI Specification Visual Documantationというサイトが便利そうでした。大事な部分はJSON Schema参照しましょう。両方見ないと分からないことがあります。 hostパラメータは任意 セキュリティ定義の（authorization uri/token uri）は絶対URLでhostとは無関係 external doucmentを使えるが、表示されない 内部用、外部用に別に分けたいが一つのファイルの方が良いです。それを表示する際にフィルタリングするようにしましょう。 よく使うDefinitionの参照先は2つあります。 Request Definition Response Definition Definition descriptionの中にはGitHub Flavoredが使えるものと使えないものがあるので注意してください。 4. Lightning Talks by Open API Initiative members! ここではLTとしてOpenAPI Initiatizeに参画している企業からその取り組みについて紹介がありました。 Mashape Augusto Mariettiさん Mashapeは開発ツールを提供しています。API管理用ツールを提供しています。 マーケットプレイス APIゲートウェイ（Kong）、オープンソース Gelato - Developer Portal キーの管理もできる アクセス管理 Swaggerサポート Galileo API解析 APIトラフィック Paypal 岡村純一さん PayPalはなぜ参加しているのか？それは二つあって、 対外的要因：より多くの人に使ってもらうため 対内的要因：製品を効率よく開発するため PayPalのAPIが他のAPIと共通化されていれば使ってもらいやすくなるでしょう。内部APIも共通化されると内部でも開発しやすくなるんじゃないかと考えています。 PayPalは単なる決済APIからペイメントOSへと発展しています。社内の開発体制が大きくなっていくと、様々な言語で作られるようになります。一貫性を保つ、コミュニケーションコストの増大を防ぐのに共通フォーマットが必要になると考えています。 IBM 森住祐介さん IBM API Connectについて紹介します。StrongLoopを買収したことでAPIの作成、実行、管理、保護までできるようになりました。 どうやって迅速に開発するのか APIを実行するランタイムの品質と性能を確保するには？ 管理を効率的に行うには？ APIをセキュリティに運営するには？ クラウド、オンプレミスで柔軟に利用可能です。開発時、ローカルも使えます。 CLIでOAIに則った仕様書を作成できたり、GUIも提供されています。 Microsoft 佐藤直樹さん Visual Studioプロジェクトテンプレートではアクセス制約、セキュリティを意識する場合はAPIゲートウェイが使えます。SwaggerからのAPIインポートがサポートされています。API AppsとLogic AppもSwaggerで連携できます。 Swashbuckle がSwagger API定義が生成します。Visual Studioにデフォルトで入っており、オープンソース・ソフトウェアです。API定義、CORS設定がLogic Appsとの連携を担います。Swaggerの直接読み込みやAPI Appsとの連携が行えます。 なお、Microsoftでは自社でも積極的に自社製品を使っています。 Microsoft REST API Guideline が最近リリースされました。ぜひご覧ください！ Apigee 関谷和愛さん ApigeeはAPI管理サービスを提供しています。Swagger EditorはApigeeのコントリビューションですが、Swagger UIは別な会社です。この辺りが連携での齟齬につながっているのだと思います。 OASについては次のようなサービスでサポートしています。 APIゲートウェイ / Apigee Proxy 利用者ポータル / Apigee Edge API開発環境 / Apigee API Studio テスト・監視 / Apigee Test OpenAPI Specificationは今後のAPI開発において無視できない仕様となっていくでしょう。今回の勉強会では余すところなく、それらの情報がキャッチアップできていたと思われます。

開発したAPIを広めるために行っていきたい施策を紹介します。ただ漫然と公開すれば良いのではなく、より広めていくための活動を行ってこそ、APIを使ったビジネス化が実現できるようになるでしょう。 自分たちが率先して使う 開発したAPIを外部企業に使って欲しいと待っているだけではダメです。そのAPIを自ら使って新しいビジネスの可能性を見せなければなりません。少なくとも基幹システムの中で使ったり、サーバサイドのレンダリングだった部分をAPIベースに置き換えると言った利用が考えられます。 自ら使うことでAPIの問題点を知ったり、改善に繋げられるようになります。使い方によっては未知のエラーが発生したり、機能の過不足に気付かされることでしょう。 事例を作る 逆説的ではあるのですが、率先してリスクをとって挑戦していく企業は希です。多くは先鞭をつけた事例を見て、自社への適用法を考えることでしょう。そのため、事例がなければ誰もが躊躇してしまうはずです。 自社自ら事例を作ることもできますし、パートナーへ依頼して事例を作ってもらうこともできます。なお、その際には事例として掲載することを予め承諾を得ておくと言ったことや、事例化することによるメリット（メディアへのパブリッシングなど）を明確にしておく必要があります。多くの場合、APIを利用したという事例化によるクライアント側企業のメリットは多くありません。 頻繁な更新と機能追加 更新が途絶えたAPIは誰も使いたいと思わないでしょう。APIという特性上、あまり更新が頻繁なのも考え物ですが、それでもトレンドに合わせた機能追加やパフォーマンス向上をしていくべきです。 互換性の維持と機能追加は矛盾することもありますが、バージョン管理を意識した運用も考えるべきです。 ドキュメントの充実 APIの利用法は、内部の人にすれば常識的であったり、察するレベルだったりするかも知れません。しかし外部の開発者にとっては全くの未知なるもので、簡単なドキュメントを読んだだけですべてを理解するのは不可能です。 ドキュメントは徹底して充実させなければなりません。APIはシステム向けのものなのでついSwaggerなどで自動生成したものだけになりがちですが、他にもチュートリアルやサンプルなど、提供すべきドキュメントはたくさん考えられます。 使えるサンプルコードの提供 一言でサンプルコードと言っても多くのパターンが考えられます。まずHello World級の簡単なものが考えられます。これは基本です。次により実践的なコードが考えられますが、これが大きな問題になるでしょう。 あまり複雑なものは開発者が理解するだけでも大変であったり、本質的ではないコードも増えてしまいます。かといって提供側の視点だけでサンプルを書くと、あまり使い物にならないコードができてしまうでしょう。これは利用者の意見を聞きつつ、使えるコードは何かを考えていく必要があります。 利用開始までの敷居を極力下げる 多くの利用者が増えないAPIは利用開始までのステップがとても多いことが問題です。Slackはチャット連携アプリケーションが爆発的に増えましたが、その大きな要因となったのは利用までの手軽さだったと言えます。 複雑な仕組みが必要な場合は専用ライブラリであったり、SDKの提供が欠かせません。ただしその場合はソフトウェアの使い方を覚えたり、そもそもの開発コストがかかってしまうのが難点と言えます。 なるべくシンプルに、すぐに使い方を覚えられて使いこなせる、そんなAPIを開発すべきでしょう。 APIによるビジネス変化は待っていければ起きるものではなく、自分たちから率先してアクションを起こしていかなければなりません。開発が必要である以上、よほどのメリットがなければ利用しようと考えないはずです。 相手にとっての利便性を第一に考えた上で、APIの仕組みや利用までの手順、サポートなどを充実させていきましょう。

APIにはHTTPアクセスをそのまま提供するだけのものもありますが、SDKや専用ライブラリを提供しているものもあります。今回はそんなSDK、ライブラリを利用する（または提供する）メリット、デメリットを挙げたいと思います。 メリット 利用者側の視点で考えた場合、次のようなメリットが考えられます。 HTTPアクセス部分を意識しないで済む APIにおけるHTTPリクエストの作成を意識しないで済むようになるのがSDK/ライブラリのメリットです。特にOAuth2リクエストのように署名を生成するような部分は実装が面倒、かつ検証も大変なのでメリットがあります。 これは提供側にとってもメリットがあります。自作ライブラリでのアクセスは当然エラーが頻発します。また、予想外のアクセス方法をしてくるかも知れません。SDKであれば、自分たちが開発している範疇でのアクセスに限定されますので、パフォーマンスを向上させる計画も立てやすくなります。 APIのバージョンアップを気にしない APIをバージョンアップした際には項目が追加または削除されたり、構造が変わったりする可能性があります。HTTPアクセスを通して使っている場合、こういった変化がシステムエラーにつながるためにバージョンアップを躊躇してしまいがちです。 SDKを使っている場合、そうした差分はSDKで吸収できます。SDK側で過去のバージョンに合わせたレスポンスに加工しておくことで、不用意なエラー発生を防ぐことができます。 デメリット SDK/ライブラリの提供によるデメリットは多数あります。このため、開発者によっては導入を控えてしまうと言うのはよくある話です。 SDK、ライブラリのバグ SDK、ライブラリがバグを含んでいたりすると、開発者にはとても嫌われる要因になります。開発者は自分の開発した範囲については責任を持ちますが、それが他者の開発したコードに起因するものだとするととてもストレスを感じるものです。 特にスマートフォンアプリの場合、修正と審査によって時間がかかるため、修正が即座に反映されません。そのため、SDKがバグを多く含んでいる場合、開発者はサービス自体の利用を止めてしまう可能性があります。 提供側としてはバグを含めないようにするのはもちろんのこと、省メモリであったり、サイズを小さくする、オープンソースにすることで開発者自身が原因を調べたり改善できる可能性を残すと言った回避策が考えられます。 特にSDKの場合、ネットワークがオフラインである場合を考慮して開発する必要があります。APIはネットワークがなければ意味がありませんが、オフライン時にメソッドをコールしても正しく動作し続けなければなりません。 動作が重たくなる可能性 SDKのサイズが大きかったり、余計なことをしているために動作が重たくなることがあります。開発者としては自分の作成したシステムやアプリが重たくなるのは嫌います。それがSDKのようにブラックボックス的に使っている部分だと特にです。 もちろん、SDKによって動作が軽くなると言うのは難しいですが、全体のコード量を減らせる可能性はあります。提供側としてはそういった視点で開発する必要があるでしょう。 更新が面倒 SDK/ライブラリが頻繁にアップデートを繰り返す場合、開発者はアップデートが面倒に感じてしまうものです。せめてパッケージ管理システムを利用するなどアップデートの手間を減らすべきです。 また、SDK/ライブラリレベルでのインタフェースは統一しておかなければなりません。インタフェースが変わってしまうとコードの修正が必要になりますので開発者にとって大きな負担となります。そのため引数も直接指定するのではなく、ハッシュを使って柔軟に設定できるようにしておくなどの工夫が必要です。 他のライブラリとのコンフリクト SDK/ライブラリによってはさらに外部ライブラリを使っているケースがあります。また、Webサービスやスマートフォンアプリは他にもたくさんのライブラリを導入しているでしょう。そうした外部ライブラリとコンフリクトを起こすのは危険です。開発者は取捨選択しなければならないからです。 時に、ライブラリの読み込み順番によってエラーが出たり出なかったりするケースがありますが、これは開発者にとって大きなストレスになります。SDKの信頼性にもつながるでしょう。 提供側としては自分たちのコードだけでなく、外部ライブラリとの組み合わせによるテストも行わなければならないでしょう。 SDKインタフェース SDKやライブラリはただ動けば良いという訳ではなく、そのインタフェースや設計思想が開発者に与える印象は大きいです。SDKはモダンな開発手法を使い、インタフェースもモダンである必要があります。 モダンな開発手法もトレンドがあります。パッケージ管理も状況が変わります。そうした開発トレンドに合わせてバージョンアップしていく必要があるでしょう。 開発コスト 提供側にとって大きな問題は開発コストです。プログラミング言語は多数あり、どれに対してライブラリを提供するかが問題です。一度の提供は簡単ですが、バグフィックスであったり、APIの更新に合わせた修正は大きなコストにつながるのでライブラリのプログラミング言語の選定は注意が必要です。 APIの利用を広める上でSDK/ライブラリの提供は大きな意味を持ちます。しかしその品質によっては開発者の信頼を大きく損なったり、API自体の採用を控えてしまうことになりかねません。提供側としてSDK/ライブラリを提供する場合は慎重な設計と品質、パフォーマンスに十分気を配る必要があるでしょう。

APIを多用して開発を進めていると、次第にシステムが複雑になってくるのが実感できるはずです。要因を挙げつつ、その回避策を紹介します。 APIの種類の増加 データを検索、加工、保存、外部への通知など様々なデータソースに対してAPIリクエストを行っていると、その管理が煩雑になってきます。最も大きなリスクとしては、一社のサービスが停止した場合に処理全体が止まる可能性があることでしょう。また、契約も複数企業と行うことになり、サービスレベルの統一も難しくなります。 回避策として、多くの企業ではなく一社にまとめてしまうという方法があります。特定企業だけが提供する機能である場合は難しいですが、クラウドサーバのような汎用的な機能であれば選定先は数多く存在するでしょう。そうしてAPI提供企業を絞り込むことで、サービスレベルの統一が可能になります。依存リスクは高まりますが、元々使っているAPIがあるのであれば一定のリスクは存在するでしょう。 ネットワーク接続先の増加 APIは一般的にHTTP/HTTPS接続によって提供されるので、実行するAPIが増えればその分、ネットワークの接続先が増えていきます。ユーザからのリクエスト、サーバからAPIのコールとその結果待ち、そしてユーザへのレスポンスと複数のネットワークコールが行われると、その分レスポンスが遅くなってしまいます。 回避先として、JavaScriptベースのAPIがあればユーザブラウザから直接コールしてもらうという方法があります。そして、ユーザが受け取った結果を自社サーバに転送してもらうのです。 ネットワーク遅延に伴う実行速度低下 APIで最も問題になるのがネットワークの遅延です。特に複数回APIをコールしなければならない状態において、一つのAPIコールの結果を待って処理しなければならない場合は大きな問題になります。 こうした問題はAPI同士が密結合することによって起こります。しかしAPI自体はなるべく疎結合になっているべきで、システムの設計上問題があるかも知れません。また、ネットワークアクセスはnode.jsのように非同期実行できる言語を採用したり、バックグラウンド処理に回すことでユーザレスポンスを改善できる可能性があります。 サービス終了に伴うリスクの増加 APIを使う上での最大のリスクと言えます。これを回避するのは契約上の縛りと、代替サービスを平行して使う方法があります。 ビジネスで使うAPIであれば、SLAの保証は適切に行われなければなりません。その意味において、無料で提供されるAPIほど怖いものはないでしょう。無料だからと気軽に使っていると、API提供側もビジネスとして成り立たず、突然終了する可能性があります。 代替サービスを常に探しておくのも大事です。世の中には数万のAPIが存在しており、類似APIは多数存在します。ただしインタフェースが異なるケースは多いので、APIコール部分をラッピングし、代替サービスへの乗り換えを容易に行えるようにあらかじめ準備しておくのが良いでしょう。 一旦複雑化したシステムをリファクタリングするのはそうそう簡単なことではありません。あらかじめそうしたリスクを勘案し、設計やコーディングに反映しておくのが大事です。

今回は、メール配信やメールマガジンサービスにおいてAPIが提供されているサービスをまとめました。メールマーケティングは今なお根強く使われている手法で、API連携によってマーケティングオートメーション、ワントゥワンマーケティングが実現できます。 WEBCAS WEBCASは、毎時300万通にも及ぶ大量高速メール配信が可能なメール配信システムです。既存システムに連携するためのAPIも用意しているため、想定のシステム構成に合わせて自由に設計が可能です。 WEBCASのAPIではバッチ処理がサポートされており、顧客リストを自動で取得し、任意のタイミングでWEBCAS管理画面からメール配信できます。その結果、業務処理の効率化が実現できます。 配信データ連携として、メール配信リストの取り込みや、CSVデータ形式でもアドレスを一括登録できるようです。その他、メール配信だけではなく、メールマーケティングにも利用できる機能があり、非常によく考えられたシステムです。 クルメル クルメルは、自社システム等の顧客情報などからAPI連携を行います。機能としては、顧客リストのアップロード、メール情報や配信エラーなどAPI連携を中心に基本機能を抑え、マーケティングに必要な情報も取得できるので、既存CRMとの連携も設計しやすそうです。 ※ 無料トライアルもあるようです。 Cuenote FC 会員データーベースと連携してメールを送ることはもちろん、レコメンド機能やDMPなど外部連携も可能となっています。 メール配信としては配信リスト登録、メール文書登録、配信予約などとなっており、これらの機能は外部システムから制御可能です。 既存の会員データベースをCSVインポート機能を利用して連携できるので、初期の導入には手間が掛からないのではないでしょうか。 ※ 試用版があるようです。 スリーメール 既存システムや独自データベースとの連携が可能で、通信はXMLで行います。他にも、基本的な配信機能に加えて添付ファウルウィルスチェックなどセキュリティも充実しており、最大で時間当たり100万通の高速配信を実現します。 クライゼル クライゼルのメール配信APIは、CRMシステムがベースとなっていて、メールマーケティングを組み合わせて利用することで威力を発揮します。 他にもCRM機能へのAPIもありますが、メールAPIとしては、会員登録、メールアップロード、配信予約と基本的な機能がそろいます。 コンビーズメールプラス 既存のシステム構成にコンビーズからもAPI連携を行うことで、メール送信等を行うシステムです。そのため、既存のシステムに合わせて自由に設計できるAPIとなっているのですが、逆にカスタマイズする必要もあるでしょう。 また、APIはβ版とあるので、開発時には注意が必要です。機能的には読者登録はもちろん、予約配信、配信状況、配信グループの設定などの機能があり、メールAPIとしての基本的な機能がそろっています。 開封率の確認などもできるので、メールマーケティングにおいても有用でしょう。 auto-mail auto-mailは、メール配信を外部システムから簡単に連携できるシステムです。XMLでの配信を行い、必要な情報もそこに含めて送信するのでAPI通信といっても特に複雑な開発は必要ないようです。 また、メールアドレスの個人情報なども90日で自動削除してくれる機能がついてます。最近では情報セキュリティで問題になる事も多くなっていますので、この機能はメール管理者としては嬉しいのではないでしょうか？ いかがでしょうか。各サービスともに基本機能はほぼカバーしており、後は既存システムとの設計の柔軟性、価格と機能の割り切りかたで、ほぼ絞られるかと思います。 自社システムはもちろんですが、企業戦略上の相性が問われるでしょう。ぜひ本記事を参考にしてください。

APIを設計する上でバージョン管理をどのように行うかは常に頭を悩ませる問題です。しかし、そもそもバージョン管理が必要なのでしょうか。今回はそんな問題提起と、その解決策の紹介です。 結局バージョン2が出てこない APIのあるある問題として、バージョン管理を盛り込んだのはいいけれど、結局新しいバージョンが出てこないという問題があります。いつまでも/v1/のまま運用していないでしょうか。ムダにURLを長くしてしまっているだけの可能性があります。 ポリシーが不明確 v1のまま運用しているからといって、APIが全く更新されていないかといえばそうではありません。多くのサービスはきちんと運営されており、APIもそれに合わせて更新されています。しかしv1に機能追加という形で行われている場合がほとんどです。 問題はどういった場合にv2にするかというポリシーが不明確であるということです。バージョンを上げる理由をきちんと作らなければならないのですが、あまり頻繁にあげると開発者を混乱させる可能性があったり、過去バージョンのレスポンスをサポートし続けなければならないといった運用上の問題も出てきます。 一部だけ更新はありえない さらに一部の機能だけ v2 になるということはありません。開発者としてもある機能を呼ぶときだけ v2 を、それ以外は v1 を呼ぶというのは非常に面倒になります。そこで基本的に全機能が v2 となっても利用でき、一部の機能だけ v2 として提供されるのが一般的です。つまり古い機能についてはエイリアスになります。 その場合、ドキュメント整備の問題があったり、実際には v1 と v2 の機能が同じなど開発者を混乱させてしまう可能性があります。 解決策 APIのバージョン管理については幾つかの方法がありますが、多くの場合開発者や、その開発者が使っているアプリごとに使いたいバージョンは決まっているという事実があります。そこで、利用するAPIのバージョンを設定画面を使って指定してもらうという方法が考えられます。 そうすることで、URL上からはバージョン番号を消すことができます。常に同じURLにアクセスするので利便性が高まるでしょう。また、運営側としてもどのバージョンのAPIが使われているかを管理しやすくなり、過去バージョンのAPIに対する保守管理を行うかどうか判断しやすくなります。 または思いきってバージョン管理を考えないという方法も考えられます。おそらく殆どの場合において、バージョン管理は利用されません。であれば、常に同じエンドポイントをメンテナンスし続ける方が安心ではないでしょうか。バージョン番号による余計な分岐処理はコードを見づらくしたり、後方互換性における開発コスト増につながります。そういった余計なコストをなくせるようになるでしょう。 適切なAPIのバージョン管理は適切なポシリーがあってこそ成り立つものです。もしバージョン管理を設計に含めるのであれば、まずポシリーの設定が求められるでしょう。

クラウド化の進歩によってビッグデータが扱えるようになり、更に脚光を浴びている機械学習。実は事の発端は意外に古く、1950年代には研究が始まっていたとされています。今回は、機械学習のAPIについてまとめてみました。 Prediction API Googleの機械学習サービス Prediction API です。トレーニングデータの学習など、RESTful APIをサポートしており、Cloud Platform の各サービスとシームレスに連携が可能です。 それはGoogleスプレッドシートにも及び、直接スプレッドシート内でPrediction APIが利用できます。これは、他にはないアドバンテージではないでしょうか。具体的にはSmartAutoFillというプラグインをAdd-onするのですが、 使ってみたところ、セルを選択するだけという手軽さで予測値が取得できます。 Smart Autofill Spreadsheets Add On ドキュメント類は殆どが英語となっていますが、非常に見やすい内容となっております。まだオープンソース化して間もないですが（2015年11月にオープンソース化）情報などはこれからどんどん増えていくことでしょう。 料金体系などは、無償と有償の2つとなっていて、無償枠では確認で試すのに十分な数値となっているようです。詳しくは、以下の料金体系を参照して下さい。 SLAについては 有償サービスで99.9% の稼働率となっています。詳しい 料金体系はこちら です。 ドキュメント クイックスタート Microsoft Azure Machine Learning MicrosoftのAzureサービスにおける、機械学習サービスです。主に、Machine Learning Studioのグラフィカルインターフェースが素晴らしいのですが、GUIでの操作の他にもAPIでの操作も可能となっています。 無料枠での利用では、ステージングでの運用のみ可能となっており、実稼働環境に移行した際にエンドポイントを取得するには、スタンダードプラン（後述）以上が必要のようです。 ドキュメントはほぼ日本語での資料がそろっており、チュートリアルもグラフィカルインターフェースの管理画面が解りやすく説明されています。書籍も販売されており、学習コストは低いと考えてよいでしょう。 料金体系はAzureとは別となっており、Freeプラン、スタンダードプランの2種類となります。スタンダードプランでは、完全な従量課金制で1000〜2000円程から利用できます。詳細な価格については 価格の詳細ページ を見てください。 SLAにおいては「マイクロソフトは、Request Response Service (RRS) に関して API トランザクションの 99.95% の可用性を保証します。」とあります。 ドキュメント チュートリアル Amazon Machine Learning| AWS AWSでの分析系サービスの一つ、Amazon Machine Learningです。 ドキュメント類は英語ですが、非常に内容が充実しています。ちょっと解りにくいのが、どこにサービス自体があるのかが、サービスが多くわかりにくいかも知れません。 コンソールにログイン後、分析のエリアにありますので探してみて下さい。また、リージョンは執筆時点ではアメリカ東部とEU（アイルランド）のみとなっています。 具体的な操作については、チュートリアルを一通り行えば、大体解るでしょう。 料金などAWSは非常に解りにくいのですが、データ分析およびモデル構築料金は他のサービスと比べ、0.42 USD/時と割合高めに設定されているようです。詳しくは データ分析およびモデル構築料金 を参照下さい。 12ヶ月のAWS無料利用枠で、AWSAmazon Machine Learning サービスは現在利用できないようです。注意文言をスルーしてしまいそうになりました。利用時には注意して下さい。 ドキュメント チュートリアル bigml bigmlは、クラウドで機械学習の予測分析ができるAPIサービスです。画面はグラフィカルで使いやすく、小難しい機械学習という感じはしません。ログインすると、すぐに使い始めることができます。 サンプルデータもいくつか用意されていますので、一通りさわってみることで、大まかな感じは掴めると思います。 Webサービスでは、RESTFullによるAPIも用意されており、全ての制御が可能となっています。ドキュメントもしっかりしていますので、利用に迷うことはあまりないでしょう。 ドキュメントはこちら です。 料金は、月額プランが30ドルからで、年間プランで一括請求であれば、年240ドル（月額換算で20ドル）からとなっています。ただし、利用サイズやデータ量にもよるので注意が必要です。 indico ログインするとAPI Keyが発行されますので、それを利用してすぐにコーディングが始められます。Python、Ruby、Java、NodeJS、PHP、Rのサンプルもついていますので、 プログラミングに慣れていれば、すぐに理解できるでしょう。 以下のデモは、テキストのSentiment度合いのサンプルです。実際のコーディング例もついているので参考になると思います。 APIは、1万コール/月まで無料となっており、それ以降は、有料となりますが比較的低料金です。また、現時点では対応言語が英語となっていますが、手始めに取りかかるには、非常に簡単に始めることのできる機械学習サービスAPIだと思います。 機械学習というと、なにやら難しく構えてしまいそうです。しかし、実際に手を動かしてみると当初思ったほどではなく、回帰分析やベイジアンフィルターなど、そのようなことは深く考えなくてもあっさりと動いてしまうという印象を受けました（とはいえ知っていた方が間違いないです）。 企業における情報処理では、ビッグデータを活用して データのフィルタリング、商品レコメンドなどが当たり前のように導入されており、それが身近に感じられるようになってきています。殆どのサービスで無料枠があるので、ぜひこの機会にいじり倒してみてください。

6月23日（木）にEnterprise APIs Hack-Night #5が開催されました。前回からxTechを全体のテーマとしており、今回はRetailTech × APIとなっています。こちらの記事は各登壇者の内容レポートです。 モノのハブステーション「minikura API」 登壇者：寺田倉庫 システムグループ藏森安治さん モノのハブステーション minikura API from minikura 寺田倉庫は1950年創業の企業で、Webサービスは5年前、Web APIは2年前から出しています。 minikuraを簡単に説明すると、Webで申し込みできるトランクルームになります。通常のトランクルームは契約はもちろん、利用も面倒です。さらに借りた後も車に積めたり、鍵を開けたりするのが面倒でした。mikuraはWebで申し込みもできて、荷物を送るのも簡単にできます。送られてきた物は検品し、一点一点データベース登録します。 そして、minikura APIはminikuraの全機能が使えます。ものを入れる、入れたものを見る、入っているものを出すの3種類の機能がベースとなっています。開発はまずAPIから行うようになっており、現時点で150本を超えるAPIを提供しています。バイマのリセール、エアークローゼット、サマリーのサマリーポケットなどといったサービスのバックヤードも提供しています。 minikura APIのここだけの話 エンタープライズ企業におけるAPI化の方法 API提供によって、語るべき人に語ってもらえるようになりました。私たちは消費者と距離がありますが、各サービス事業者がサービス利用者に分かりやすい形でサービスを紹介してもらえています。その結果、これまでにない商品を預かるようにもなっています。 私たちはすでに確立したワークフローがあり、それを変更するのはとても大変でした。そこでまず会員登録だけAPI化し、徐々に広げていったのが今の形です。エンタープライズ企業におけるAPI化を担うのは開発者であると言え、その意味では開発者は失敗を恐れずやっていって欲しいと思っています。 サンドボックスが大事 minikura APIを叩くと倉庫や人が動くことになります。ちょっとした試用が業務に混乱をもたらしかねません。その意味ではサンドボックス環境がとても大事で、B2Bにおいては特にサンドボックス環境がないとトラブルになりかねません。 寝た子は起こすな 私たちは「預かるにイノベーションを」起こしたいと考えています。そんな中、私たちの業界では「寝た子は起こすな」という言葉があります。倉庫に置きっ放しになっている（塩漬け状態）になっている顧客に案内メールを出して出庫されたらたまらない、という訳です。 しかしイノベーションを起こすためには預けた上で、さらに変化をもたらしたいのです。例えば次のような妄想を考えてみました。預けた後に、倉庫内で物々交換するマーケットです。倉庫内移動なのでお互いの名前も住所も知る必要がありません。さらにわらしべ長者よろしく、交換している内に自分にとって不要だったものがとても役立つものに変わるかも知れません。 私たちはそんな形で外部からのエネルギーを取り込んで新規事業を開拓しています。本社の倉庫はまだまだICT化が進んでいません。もっとBizDevを加速していきます。 Q&A 競合他社の動き（API化について）はありますか？ minikuraについては競合がいません。競合は実家と言っています。 API化によって誤発注などに対する対策は？ 大量発注はあります。API側の開発はどんどん進んでいくのですが、現場（倉庫）はまだまだICT化が進んでいないのでそのギャップが大きいと感じています。 当日の動画 物流のクラウド化 登壇者：エアークローゼット　CTO　辻亮佑さん エアークローゼットは感動するファッションの出会いを生み出したいというコンセプトのサービスです。コーディネーターが組み合わせた洋服を期限なく借りられます。そのまま購入もできますし、返却も可能です。その際、クリーニングはいりません。 サービスを作るにあたってやらなければならないことが多数ありました。 洋服の入庫およびササゲ（採寸、撮影、原稿） 1品1品を単品管理 選ばれた服をユーザに配送 こだわりの検品、クリーニング これらをすべてまるっと依頼できるのが寺田倉庫さんでした。minikuraなくしてエアークローゼットは存在しなかったとさえ言えます。洋服というリアルのものが絡む分、インターネットだけでは解決しませんし、かといってスタートアップだけでは人も足りません。 そこでminikuraの撮影付きお預かりサービスがありました。在庫の単品管理も可能で、クリーニングもできます。倉庫から指定した住所への発送も可能です。システム連携するAPIも用意されており、出会ったときには感動すら覚えました。 具体的な活用事例について紹介します。 アイテム情報連携 アイテムの指定の日付からの差分情報が取得できます。 新規入庫アイテムの取得 どのアイテムが今どこにあるのか取得 メタ情報の連携 などの情報が取得できます。 配送伝票番号取得API 配送依頼をかけたアイテムごとに、ヤマトの配送伝票番号を取得できます。レンタル出庫したユーザへ届くアイテムの配送伝票番号を送付しています。ユーザは自分でコンビニ受け取りに変更したりできます。 レンタル出庫依頼 指定したアイテムを指定したユーザへ送付します。現物確認用にオフィスへ送付するのにも使います。 アイテム情報更新 ユーザのフィードバックをもとにアイテム情報を更新します。 総括 今は実現したいことを元に、寺田倉庫さんと相互連携しながら業務オペレーションやシステムも継続的に改善しています。例えば検品APIは元々ありませんでしたが、一緒に考えて作っていきました。minikuraのサービスを使うことで、物流面の運用はすべて任せられるのでとても役立っています。 Q&A 社内DBは何を管理していますか？ フィードバックやスタイリストに関係するデータは社内DBで管理しています。 もしもminikuraがなかったら？ このサービスはなかったでしょう。企画段階から色々な倉庫にあたっている中でminikuraに出会いました。 競合の出現については？ ファッションレンタルで言うとすでにライバルは出てきていますが、コンセプトが違うので大丈夫と考えています。 エアークローゼットとminikuraの間で情報整合性については？ 過去に何度か起こったことがあります。違うアイテムと入れ替わっていたなど。その度にフローを変えて、防止策に取り組んできました。 出庫取消は？ あります。基本的に出庫取消は電話です。また、作業量の増減もあるので、デイリーで共有しています。APIにない機能は企業間コミュニケーションで解決している。 シーズンによってスケールは？ シーズンはトレンドに影響しても出庫量についてはあまり変わらない印象です。シーズンによって冬服は奥に移動するなど、オペレーション上の工夫はしています。 リクエストした機能はありますか？ たくさんあります。例えば返送用伝票に倉庫管理番号が入っているのですが、返送用伝票がなくなるとワークフローが混乱しました。しかし、元々APIがありませんでしたので、追加してもらっています。 当日の動画 iPadクラウドPOSレジにおけるAPI活用事例 登壇者：株式会社ユビレジ 取締役 竹内歩夢さん iPadクラウドPOSレジにおけるAPI活用事例 from Pomu Takeuchi ユビレジは2010年からはじまったiPad POSアプリの元祖です。約2万店舗に使ってもらっています。基本的なPOS操作はiPad、解析系はWebブラウザで使います。アルバイトでも学習コスト少なく使えるのがポイントです。 技術面の話 ユビレジでは3種類のAPIを提供しています。 Web(HTTP)API いわゆるREST APIです。差分を取得するのに特化したエンドポイントを用意しています。商品登録や会計の取得などもできます。ユビレジ自体このAPIで実現しています。 iOS URL Scheme API iOSのアプリ間連携を実現している。ユビレジから他のアプリ（決済系など）を呼び出して戻ってくる使われ方です。iOS9から条件が厳しくなってSchemeの事前の登録が必要になっています。 iOS HTTP API iPadアプリ内にHTTPサーバが立っていて、APIを提供しています。LAN内で使われています。iOS 10で制限がかかるかも知れません。 認証方法 API Token アカウントごとにAPI認証用のTokenを幾つでも発行できます。実装が簡単で、自社システム向きです。 OAuth2 サービス提供者向けです。認証、認可のフローを自動的に行えます。APIアクセス許可、拒否をエンドユーザの負担なく行えるのが利点です。アクセストークンは1日、リフレッシュトークンも2週間程度となっていて、頻繁にアクセスしないと無効になるようにしています。 ユビレジAPIは元々私が自分で経営していた会社で最初に使ったと思います。その後、ラクーン、Salesforce、トレタ、PayPal、GMO、freeeなどでも使われています。開発者向けのサンドボックスも用意しています。 APIと関連業務について オーダー管理 オーダーアプリで取った注文をiPadアプリへ受け渡してお会計します。同一端末ならURL Schemeで、別端末ならiOS HTTP APIで行います。 決済 食べログPay、楽天Pay、PayPal Here（現在終了）などの決済アプリとの連携します。それぞれの決済アプリが持っているAPIを叩く仕組みです。 生産・仕入・在庫管理 在庫管理や棚卸しを実現します。ラクーンのスーパーデリバリーで使われています。ユビレジの商品マスタをAPIで更新する仕組みです。賞味期限の早い商品は午前中の売れ行きを見て、午後の生産調整を行うといった使い方もされています。 販売管理・顧客管理 顧客情報の登録をAPIでできます。レセコン連携、売り掛けの管理、DM発送もできるようになっています。 会計 支払い方法別の金額取得がAPIで可能です。クラウドの会計サービスと連動するのに売り上げ情報を渡しています。大型で古いERPに対してmac miniを経由してデータ連係しているケースもあります。 Q&A 導入店舗はどういった業種が多いですか？ハードルはどうですか？ 飲食店がメインです（7割）。残り2割が雑貨、アパレル。残り1割が美容院、整骨院など。新規店舗だと初回の導入コストに比べると低いので問題になりまん。チェーン店はすでに設備があるので難しいことが多いです。故障など、タイミングが必要です。 アプリによってはAndroidのものもあるが、他のOSとの連携は？ データの連係だけすれば良いのでHTTP連携も使えます。 店舗側での商品/在庫管理する上で商品IDの管理は？ バーコードをキーにユビレジにも登録しているのだと思います。 企業連携する際、どれくらい期間がかかっているのか？新しく開発しているケースはあるのか？ アプリ間の決済連携は簡単で2ヶ月くらいです。会計系はテストの工程が必要で、半年くらいかかってしまいます。新機能については話を何回か聞いています。お互いのメリットを見て判断しています。 SquareやPayPalなどもPOSを提供したりしていますがいかがでしょうか。今後決済についても提供する可能性があるでしょうか？ Squareは決済ありきでPOSはおまけ。PayPal Hereも。ユビレジはPOSありき、決済は逆におまけとしています。私たちはお互いいいとこ取りして一つの大きな仕組みとしています。 当日の動画 今回は懇親会が別会場でしたが大いに盛り上がっていました。次回は8月25日にEdTechを予定しています。ぜひご参加ください！