流通業のPOSのAPI

飲食店、店舗ビジネスの基本。APIを提供しているPOSサービスまとめ

レストランやアパレルなど、殆どの店舗で導入されているのがPOS(Point of Sales)システムです。そんな店舗ビジネスの基盤とも言えるPOSシステムにおいてもAPI活用が広がっています。

今回はそんなPOSシステムで使えるAPIをまとめました。

APIを通して広がるビジネスの可能性

企業としてAPIを提供し、かつそれをビジネスで活用していこうという動きが出始めています。今はまだスタートアップをはじめとする小規模な企業か、クラウドベンダーなどのIT系企業で取り入れられている動きですが、徐々にそれ以外の企業においても採用されつつあります。

今回はそんなAPIをビジネスで使うことによる新しいチャンスや事業拡大を目指す方法について紹介します。

多面的展開を前提に考える

これまでのWebサービスのように、PCのブラウザ向けだけに情報を提供するのであればAPIを提供する意味がありません。昨今、デバイスの種類は急激に増加しており、提供形態もまた増えています。それらを認識し、多面的展開を目指すべきです。

分かりやすいところではスマートフォンやタブレットなどのスマートデバイス、サーバサイド連携、IoTデバイス、Webブラウザの機能拡張などが考えられます。情報の発信先を限定しない観点が必要です。

見通しの良い、保守しやすいシステムへ

システムは最初に開発した時には分かりやすくとも、徐々に手を入れていく中で分かりづらく、負債へと変わっていきます。これはシステムが表示部分まで担っている場合に起こりがちです。

API化するということは、システムの表示部分を切り離すということです。すべての表示処理(アプリの画面やWebブラウザなど)はそれぞれのデバイスに任せることができます。また、iOSとAndroidなどで発生する特有の処理はアプリ側で担うことになりますのでロジックもすっきりとさせることができます。

保守しやすいシステムはシステムの運用コストを下げ、新しいビジネスの変化にも追従しやすくなるでしょう。スマートフォンに変わる新しい仕組みが登場したとしてもすぐに対応できるはずです。

システム連携の工数削減

企業間連携や提携を通じて情報の送受信が発生する場合、APIがあるとないとで大幅に工数が変わってきます。特に自分たちだけがない場合、仕様を相手に合わせて設計することになるでしょう。これは相手の企業特有のビジネスフローを含んだものになり、他企業との提携には使えないものになるかも知れません。

APIがあれば、そうした工数が一気に削減できます。もしAPIがない状態で企業連携の話が進んだ場合、そこからお互いに話し合って仕様を検討して実装して結合テストをして…といったことをしているとあっという間に1年経ってしまうはずです。それがAPIがあることで、数ヶ月もあれば完成することになります。

最近のビジネスにおいては手動ではなく自動化されることが前提となっているため、APIの有無によって完了までの時間やその後のスピード感がまったく変わってくるでしょう。

複数企業との提携が容易に

APIは自社のビジネスフローを確立するものになります。全く足りない機能があれば追加開発する必要がありますが、そうでない場合はAPIを利用する側がロジックを組んだ上で利用します。つまりAPIが標準フローを担うのです。

標準フローができていれば、後は水平展開していくだけで企業提携が進められるようになります。


ビジネスにおけるAPI利用のイメージは、Webブラウザ以外への情報発信先の拡大、他企業との提携などの利用先拡大と言ったものになるかと思います。つまりAPIを単に作るだけでは意味がなく、APIを使って何をするかが大事ということです。そのためにはAPIありきではなく、ニーズありきで考えた上で、APIという自動化、システム化を担う技術をどう組み込んでいくかが重要になるでしょう。

Orange API(link is external)

タブレットを使ったPOSシステム、EC-Orange POSが提供しているAPIです。売り上げ、商品、在庫、顧客情報を連携できるようになっています。既存の基幹システムとの連携などが想定されています。

スマレジ(link is external)

iPhone/iPadを用いたPOSレジシステム、スマレジで公開されているAPIです。売り上げ、在庫、商品データなどが取得できます。オプションにより会員情報も取得できます。

また、WebHooksにより商品、会員、在庫情報などが更新されたタイミングでHTTPリクエストを飛ばすこともできます。

ユビレジ(link is external)

iPadを使ったレジシステム、ユビレジの公開しているAPIです。売り上げデータのダウンロード、メニュー編集、顧客データの編集などユジレジでできることのほぼすべてがAPI経由で可能です。

ユビレジ for Salesforceという仕組みを使うことでユビレジの売り上げデータをSalesforceへインポートできる仕組みもあります。

Omnivore.io(link is external)

レストラン用のPOSシステムを提供しているOmnivoreのAPIです。商品、オーダー、メニュー、支払いなどすべての機能がAPIから操作できるようになっています。

poscube(link is external)

iPadを使った飲食店専用のPOSシステムを提供しています。注文データや注文履歴、商品データ、テーブル状況と言ったデータをAPI経由で利用できます。空席状況の確認などにも利用できます。

Revel Systems POS(link is external)

iPadを使ったPOSシステムを提供しています。APIを介して全データへのアクセスが可能とのことです。

Point of Sale – Developer API | Power your App with eThor(link is external)

注文や支払いへのアクセスができます。Facebookからの注文にも対応しているようです。

Shopify POS App SDK(link is external)

Shopifyは元々ECショップを作成できるサービスでしたが、POSシステムも提供するようになっています。POSアプリを提供する訳ではなく、SDKを提供する方法をとっているようで、自分でPOSシステムを組むという形になるようです。


最近ではiPadやタブレットを使ったPOSアプリがたくさん出てきています。そうしたアプリではAPIを使うのが基本になるので、パートナー向けに公開することでAPI公開が実現できます。

多くは基幹システムとの連携に用いられるようで、まさにビジネス向けのAPIと言えそうです。

APIにアクセスできない時にはどうしたらいいか

APIを使った開発、運用でよくあるのが突如としてアクセスできなくなるという問題です。今回はその際に関係する技術と解決手段を紹介します。

自社ネットワークの問題

APIは問題がなくとも、自社側のネットワークに問題が発生していることがあります。LANカードの不具合、ネットワーク設定のミス、ルータ/ファイアウォールの不具合、ケーブルの破損などが考えられます。

外部ネットワークの定期的なアクセスチェックはもちろんですが、内部ネットワークについてもきちんと確認するのが良いでしょう。こういった不具合の問題として、不具合を通知するメールも送信できなくなることです。不具合発生時の通知はもちろん、通常運用時にも定期的な通知を行うのも手です。また、別ネットワークからの生存確認を行うシステムの導入もお勧めです。

DNSエラー

ネットワーク周りでよくあるのがDNSの問題です。自社運用の場合はもちろん、ドメイン設定のミスなどでアクセスできなくなることがあります。この場合の問題としては、DNSには設定のキャッシュがあるので問題発生の確認が遅れてしまうことです。

APIからの応答がない

APIへリクエストを送ってもレスポンスがない場合、サーバが完全に停止しているか、処理が重たいために遅延している可能性があります。利用する際に適切なタイムアウトを設定しておかないとリクエストが他のキューと合わさって多重化したり、ハングしてしまう可能性があります。

APIのレスポンスに対する品質を予め確認しておいたり、計測しておくことでレスポンスの悪化を予め知ることができます。また、5秒程度でタイムアウトするようにしたり、前のキューが終わっていなかったらアクセスしないように制御します。

40X系のエラーが返ってくる

存在するはずのエンドポイントから404エラーが返ってくるとすれば、アプリケーションサーバが止まっている可能性やAPI自体が削除されてしまった可能性があります。401の場合は認証エラーが多いので、キーを再生成した可能性があります。

一般的に40X系のエラーレスポンスはシステム上の正しいエラーであることが多いので、コードの見直しを行うのが良いでしょう。

50X系のエラーが返ってくる

503はシステムエラーであったり、50X系のエラーはシステムの例外エラーであることが多いです。これは予期せぬエラーになりますのでAPIのテストが不十分であったり、データベースやストレージで問題が発生している可能性があります。API提供元への問い合わせが必要でしょう。


APIでのエラーはシステムの連鎖的不具合につながる可能性があるので、それぞれの問題の切り分けによって正しく判断し、素早い対応が求められます。ただし利用する側としてもエラーが発生することを予め見込んだ上で作り込んでおくのが大事でしょう。

カテゴリー:

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト /  変更 )

Google フォト

Google アカウントを使ってコメントしています。 ログアウト /  変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト /  変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト /  変更 )

%s と連携中