IMD APIシステムの利用 TypeC

API利用方法を前提に type C についてご説明します。

TypeC 概要 snapshot

ステップ１　必要事項の確認

一連のAPI動作のためには、次のAPIと付帯情報が必要になります。

API ・検索API クライアント認証情報（全APIに必要）・APIサーバー名・アクセスコード・アクセス認証/制限用の（貴社側アプリサーバーの）代表IPアドレス（またはトークン方式　※追加有料・条件あり）補足：検索APIは、 https://api.mobadai.jp/docs/search/に仕様が定義されています。 ※Basic認証は別途担当から入手下さい。最新となる検索API には多彩な機能が定義されていますが、ご利用になれる検索機能はご契約時に指定されたもののみとなりますので、ご了承下さい。

検索APIチェックリスト

✅　同時利用想定人数を弊社に伝える　※スケーラビリティのご相談に乗りますが、数千未満であれば概ね問題ありません ✅　利用する検索API種別を選定する　※アプリのU/Iや操作導線を考慮してご検討下さい。 ✅　利用する検索API種別の中でのオプションを選定する　※仕様書をご確認下さい ✅　検索APIがレスポンスする「栄養素」などを選択する　(データ仕様表) ✅　栄養素以外のオプションデータを選択する　※メーカー名や三階層カテゴリなど

主要検索APIの機能比較

No.	検索API区分名	文字列検索	複数検索語	新商品	unlimited	フィルタ・ソート	備考
1	食品文字列検索	〇	-	-	-	-	シンプル
2	食品文字列検索＋	〇	〇	-	-	-	汎用
3	新商品検索	〇	-	〇	-	-	新商品専用
4	カスタム食品文字列検索	〇	〇	〇	〇	〇	推奨
5	サジェスト検索	〇	-	-	-	-	検索補助用
6	食品詳細情報取得	-	-	-	-	-	OIDの詳細取得

検索APIにおいては「特定検索語システム」機能も付帯しております。 ※ 全APIについてレスポンス最大数は 500 件にさせて頂いております。 (カスタム食品文字列検索のみ、指定件数毎にページング処理でのレスポンスにも対応しております） ※「unlimited」は、コンビニ商品など同一社店名で数万件ある場合でもフィルタを通じ全商品対象にリーチできる機能です ※ 詳しくは仕様をご確認下さい

ステップ２　ご契約とご利用開始

「ご契約書雛形」をベースに、貴社のご都合に最適なプランを弊社担当と共に調整させて頂きます。 API利用方法にある通り、この事務手続きには、貴社法務のご都合が関連するため、弊社では関知できませんが、一般的に数日から一か月程度で完了するものです。 ※ご契約内容については各社さまのご意向等を経ておりますので、一般的な内容と認識しております。

ご契約の最終段階（双方法務チェックが完了し、一方から捺印書類が送信・郵送された段階）で、ご要望があれば先行して、APIの各種情報を先行納品させて頂くことは可能です。 ※この点は、応相談ですので、御見積・御請求書に本件事項記載をご確認下さい。原則として、お取引に関しては前金でお願い致しております。 ※ライセンス更新の場合、ライセンス更新前日までのご入金をお願い致しております。 ※翌月末入金についてもご要望に応じておりますが、事務手数料を頂戴致しております。

ステップ３　運用とサポート

APIについては、弊社では全て外部VPSを利用しておりますので、必要に応じてご契約時に外部業者をご確認下さい。（エコノミーAPIでは kagoya 社となっております） ※AWSなど、ご指定のVPSがあれば、追加費用と追加実費などでお承り致します。また、原則としてVPSは占有型でご提供致しますので、貴社負荷のみとなりますので、エンドユーザさまが増加された場合には、VPSを増強して頂ければ対応可能です。 ※記録APIについては単純な追加ではないため、ご相談下さい。特に検索・分析APIについては、独自の高速冗長化分散システムの構築により、 Oracle や MySQL のようなデータベースをVPSには搭載しておりませんので、発生しやすい障害としてのデータベースの齟齬や停止等は物理的に生じません。

弊社ではお電話サポート（営業時間外は留守番電話の音声認識でメールが送信されるシステムを利用しております）、メール、Webにてご対応しており、ご契約書に記載の対応時間で処置致しております。またアプリケーションレイヤにおいても、24時間自動監視システムで、異常時は速やかに対処致します。

FAQ

☑　検索APIのレスポンス時間は、どの程度を見込めば良いか？ ✅　フィルタやソート機能は動的に実施し、規模や状況に依存しますので、一概には確約できません。 LinuxベースのOSにおいて稼働するApacheが、静的な json ファイルをレスポンスする速度を最短とし、それにフィルタやソートを実施する時間が加算された程度が目安となります。また、弊社は常に占有型VPSでご提供致しますので、他社アクセス等に影響されることもなく、数十万同時アクセスなどに対しても、VPS を並列増強することで対応できるアーキテクチャを採用致しております。（AWS各種にも対応致しており、ご相談下さい。）なお、標準VPS は SSD/12core CPU の VPS となっております。そのため、実際の実装動作を検証するに、レスポンスのCPUパワーなど VPS の課題よりも、伝送のための時間（レスポンスサイズ）を考慮頂くことが重要になっております。検索APIにおいては、フィルタを活用してレスポンス数を減らし、冗長的な栄養素のレスポンスは契約段階でお控え頂くのも得策とご提案いたします。例えば、検索APIにおいては OID や名称、エネルギー等の最低限のレスポンスを実施して、レスポンスを得た後にOIDをキーとして栄養素等を取得する「データAPI/食品詳細情報取得 (追加ご契約オプション)」を叩くことを非同期で行うなどです。なお、同APIを弊社サンプルサービス（LINE版フードサーチ、同Web版フードサーチ）にて、実際に利用しておりますので、ユーザとしての反応速度は体感・検証頂けると思います。