こんにちは。VOYAGE MARKETINGでシステムを担当している@axhillです。

VOYAGE MARKETINGではポイント交換のPeXの運営の他、様々なサービスを提供しています。

今回は、そんなサービスの中の一つ、デジタルギフト・オンデマンド・サービスを開発した時のことを書こうと思います。

デジタルギフト・オンデマンド・サービスって何？

デジタルギフト・オンデマンド・サービスは、AmazonやiTunesなどのデジタルギフトコードを
Web APIを通してリアルタイムに発券することができるBtoBのサービスです。

詳しくはデジタルギフト・オンデマンド・サービス紹介ページご確認ください

プロジェクト開始当初、Web APIの設計経験に乏しかった私には、
どのように作ろう、と考えていた中で一つ思ったことがありました。
それは次のような考えです。

他社が公開しているWeb APIへの不満を整理することや
自分が利用したくないWeb　API像を想像することで、
反面教師的に、利用者からの不満が少ないWeb APIを開発できそうだ。
というわけで、プロジェクト開始早々に、自分で使いたくないWeb APIについてブレストをしてみることにしました。

ブレスト「こんなWeb APIは嫌だ」の例

■ リクエストの種類ごとにレスポンスの形式が変わる
APIごとにレスポンス形式がXMLでしか受け取れなかったり、
またJSONでしか受け取れなかったりとバラバラに指定されているのは嫌ですね。
リクエスト時にレスポンス形式を指定できるとサービス利用側の実装が楽になりそうです。
■ 稀にレスポンスが得られないことがある
ネットワークやサーバの障害が発生しないとは保障しきれません。
もちろん障害が発生すれば、Web APIでリクエストを受け取れなかったり、
レスポンスがリクエスト元に届かないことも起こりえます。
後からリクエスト・レスポンスの内容を確認できる手段があると重宝しそうですね。
■ 第三者が自分のアカウントでリクエストできる
第三者が正規サービス利用者のアカウントでリクエストを行うと、
API利用にかかる請求は当然、正規サービス利用者に乗ってきます。
そんなの嫌ですね。
Web APIとサービス利用側で、お互いに正しいリクエスト・レスポンスであることを検証できると嬉しいですね。
そもそも第三者がリクエストを行えないような制御が必要ですし、
リクエスト方法やリクエストの検証方法が第三者に漏洩しないよう、気を配らなければなりません。
■ サンドボックスが無い。または使いづらい
サンドボックスが無い場合、開発する際に自前でスタブを作る必要があるので、
サービス利用側の工数が膨らみそうです。
また、期待するレスポンスを返せるようにWeb APIを設計しておくことで
サービス利用側の開発が楽になりそうです。

ブレストを経て思ったこと

Web APIは作り方次第で、サービス利用者に大きなストレスを与えます。
経験的にストレスを受けるWeb APIの形が何となく見えていたので、今回はこのようなブレストを実施できました。
プロジェクト開始早々で、自分でも利用したいと思えるWeb APIの形が何となく想像できたのは良かったです。

デジタルギフト・オンデマンド・サービスのWeb APIについてはもちろん、このブレストの後、
調査や設計、レビューを通して開発されていますので「こんなWeb APIは嫌」にはならないと思います。

サービスを運営されている方は、他社や自社のサービスに対する不満を記録しておくと
自社サービスへの改善点として活かせることもあるかもしれませんね！


ではー。