Yahoo!・Qoo10・Amazon の3モール在庫同期API「キャメル vs スネーク」混在地獄
EC事業者がいちばん事故りやすい業務、それがマルチモールの在庫同期。弊社ではAmazon・Yahoo!ショッピング・Qoo10・自社ECの4モールを並行運営しているが、特にYahoo!とQoo10のAPI実装でどうしても乗り越えられない壁にぶつかった。それが「APIキー命名規則の混在地獄」だ。【問題の発端】VOMS(自社SaaS)の在庫同期機能を実装中、Yahoo!の商品情報を取得する処理で何度叩いてもmissing required parameter: sellerIdエラー。リクエストには確かにseller_idを渡しているのに認識されない。ドキュメントを再確認したら、まさかの仕様:・Yahoo!ショッピング 注文API:sellerId(キャメルケース)・Yahoo!ショッピング 商品管理API:seller_id(スネークケース)同じYahoo!のAPIなのに、商品管理APIと注文APIで命名規則が違う。【各モールの命名規則カオス】◆Yahoo!ショッピング・注文API:キャメルケース・商品管理API:スネークケース・在庫API:スネークケース・ダウンロード受信箱API:キャメルケース→同じプロバイダー内で混在◆Qoo10・商品API:パスカルケース・注文API:パスカルケース・クレームAPI:一部キャメルケース→統一感はあるがメソッド名がドキュメントと異なる場合がある◆Amazon SP-API・全API:スネークケース→Amazonは比較的統一【Qoo10で更にハマったメソッド名問題】Qoo10で「公式ドキュメントに書いてあるメソッド名が間違っている」という事案に
0