【ITニュース解説】I built a nutrition API, got 54 signups and made $0. Two bugs were hiding in plain sight

このニュース記事は、ある開発者が食事と栄養に関するAPI（Application Programming Interface）を構築し、それをRapidAPIというAPIマーケットプレイスに出品した経験を述べている。APIとは、異なるソフトウェア同士が連携し、情報をやり取りするための仕組みのことで、このAPIは利用者が食品名で検索すると、その食品のカロリーや主要な栄養素（タンパク質、脂質、炭水化物）といった詳細な栄養情報を取得できる機能を提供する。具体的には、バーコードを使った食品検索、アレルギー情報の検出、食品の健康スコア評価、特定の食事要件に合わせたフィルタリング、そして食事計画の計算といった多彩な機能が盛り込まれていた。技術的には、JavaScriptのWebアプリケーションフレームワークであるExpress.jsとプログラミング言語のTypeScriptが使用され、Vercelというクラウドプラットフォーム上にデプロイされていた。データの情報源としては、アメリカ農務省のFoodData CentralとOpen Food Factsという信頼性の高い食品データベースが利用されている。

APIは公開後、無料プランに54人ものユーザーが登録したが、開発者は誰も有料プランへアップグレードしないという問題に直面した。この状況を詳しく調査した結果、APIの中に二つの重大なバグが潜んでいたことが判明した。これらのバグは開発当初から存在していたにもかかわらず、テスト不足のために見過ごされてきたものだった。

最初のバグは、特定の食品IDを使って食品の詳細情報を取得する際に、その食品のカロリーが常に「0」と表示されてしまうという問題だった。例えば、バナナの栄養情報を取得しようとすると「バナナは0カロリー」といった誤った情報が表示される状態である。この原因は、データの提供元であるUSDA FoodData CentralのAPIが、検索結果として複数の食品リストを返す場合と、特定の食品の詳細情報を返す場合とで、栄養素のデータ形式が異なっていたことにある。検索結果では栄養素データが{nutrientId, value}という形式で提供されるのに対し、特定の食品の詳細情報では{nutrient: {id}, amount}というように、nutrientというキーの下にさらにidがネストされた、より複雑な形式で提供されていた。開発者のコードは、この二つのデータ形式のうち、シンプルな{nutrientId, value}形式にしか対応していなかったため、詳細情報を取得するAPIが呼び出された際には、正しいカロリー値を読み取ることができず、結果として「0カロリー」と表示されてしまっていたのだ。検索結果の一覧では正しいカロリーが表示されていたため、開発者はこのバグに気づきにくかった。この問題の解決策は、異なるデータ形式を適切な形式に変換する小さな関数を追加するだけであった。

二つ目のバグは、APIの料金プラン設計そのものを無効にしてしまう、より深刻な問題だった。本来、このAPIはRapidAPIというマーケットプレイスを通じて提供され、利用者は無料プランのリクエスト制限を超える場合に有料プランに登録することになっていた。しかし実際には、RapidAPIを経由せずに、開発者がVercelにデプロイしたAPIの生のURLに直接アクセスするだけで、誰でも無料でAPIを無制限に利用できてしまっていたのだ。これは、APIのドキュメントにVercel上のAPIの直接URLが誤って記載されていたことに加えて、APIサーバー側で、リクエストがRapidAPIを介して送られてきたものなのか、それとも直接送られてきたものなのかをチェックする仕組みが実装されていなかったことが原因だった。この結果、ユーザーが有料プランに登録する動機が全くなくなり、54人全員が無料プランのまま利用し続けるという状況が生まれていた。このバグを修正するため、開発者は今後のすべてのAPIリクエストに対して、RapidAPIが発行する秘密のヘッダー（RapidAPI経由であることを示す認証情報のようなもの）を添付することを必須とした。このヘッダーを持たないリクエストは、今後403エラー（アクセス拒否）として処理されるようになり、RapidAPIを通じた正規の利用ルートのみが許可されるようになった。

これらの主要なバグの他にも、APIの掲載情報（リスティング）に、実際には存在しないエンドポイントが記載されていたため、その記述も修正された。

これらの経験から、開発者はいくつかの重要な教訓を得た。一つ目は、ユーザーが最初に目にするデモ用のエンドポイントだけでなく、実際にユーザーが深く利用するであろう「2番目のエンドポイント」（この場合は、検索結果からさらにクリックして表示される詳細情報のエンドポイント）もしっかりとテストすることの重要性だ。二つ目は、RapidAPIのようなマーケットプレイスを通じてサービスを提供する場合は、そのマーケットプレイスがAPIへの唯一のアクセス経路であることを確実に設定する重要性である。そうしないと、今回のように料金プランがバイパスされてしまう可能性がある。そして最も重要な教訓として、自動テストの価値が挙げられた。もし開発の初期段階から自動テストが導入されていれば、これらの二つのバグは開発初日に発見され、修正できていたはずだ。この反省から、開発者は新たに10個の自動テストを追加したという。

現在、このAPIはフィットネスアプリ、食事計画アプリ、食料品管理アプリなどの開発者向けに、月100リクエストまで無料のプランを提供している。有料プランは月額3.99ドルで1000リクエストが利用できる。開発者は、このAPIの価格設定や、他社の類似API（EdamamやNutritionixなど）と比較して何が不足しているか、どのような機能があればさらに魅力的になるかについて、ユーザーからのフィードバックを積極的に求めている。この開発者の経験は、ソフトウェア開発、特にAPIの開発と運用において、細部にわたるテストとセキュリティ設計がいかに重要であるかを学ぶ良い事例となるだろう。