こんにちは。@takokkeです
現在、地方のWebマーケティングの会社で、長期インターンを行なっています。
来年からSEになるということもあり、スキルアップのために、業務から吸収する日々・・・と言いたいところですが、最近は惰性でやっており、お金が目的になっちゃってます。
背景
kintoneとWordPressを連携する案件で、レコード編集時にWordPressのACF APIを叩いて画像をアップロードする仕組みを作ろうとしました。
最初は「kintone.proxyを使えばCORS問題も回避できるし楽勝！」と思っていたのですが…実際にやってみると色々ハマったので備忘録としてまとめます。
試したことと結果
1. kintone.proxy + バイナリ送信
まずはバイナリをそのまま送信してみました。
// ここにバイナリ送信のコード例を載せる
しかし結果は 「権限がない」エラー。
ただし、同じユーザーでWP管理画面から直接アップロードは可能でした。
2. kintone.proxy + FormData送信
次にFormDataを使って multipart/form-data で送信。
// ここにFormData送信のコード例を載せる
しかし今度は
「Content-Dispositionを指定しろ」 という謎エラーが発生。
通常、FormDataを使えば自動で付与されるはずなので、これは明らかに挙動がおかしい…。
3. WordPress側の問題かどうか、Postmanで検証
「WordPress側の問題か？」と思い、Postmanでテスト。
バイナリ送信 → 成功
FormData送信 → 成功
この時点で、WordPressやACF API自体には問題なし、kintone.proxy特有の制約と確信しました。
4. fetchで直接リクエスト
最後に fetch() を使って、kintoneから直接WordPress APIを叩いてみました。
// ここにfetchでFormData送信するコード例を載せる
結果は 問題なくアップロード成功！ 🎉
得られた知見
kintone.proxyはJSONやBase64文字列転送には強いが、バイナリやmultipart/form-dataには弱い。
WordPress ACF APIの画像アップロードにはFormData必須。
画像などのバイナリを扱う場合はfetchを使った方が安定する。
まとめ
今回の学びを一言でまとめると：
kintone.proxyはCORS回避には便利だけど、ファイルアップロードには不向き。
画像を扱うなら素直にfetchでやった方が早い。
追記：kintone.proxy.upload が存在した
記事を書いたあとで気づいたのですが、公式には kintone.proxy.upload というメソッドが用意されていました。
これを使えば、通常の kintone.proxy よりも直感的にファイルアップロードができます。
公式ドキュメント：
https://cybozu.dev/ja/kintone/docs/js-api/proxy/kintone-proxy-upload/
サンプルコード：
(async () => {
// kintoneファイルフィールドから画像ファイルを取得する場合
// ここではテスト用にBlobを生成
const blob = new Blob(['ダミー画像データ'], {
type: 'image/png',
});
const data = {
format: 'RAW', // バイナリとして送信
value: blob
};
try {
const resp = await kintone.proxy.upload(
'https://example.com/wp-json/wp/v2/media', // WPメディアアップロードエンドポイント
'POST',
{
'Authorization': 'Basic ' + btoa('wp_user:application_password'),
'Content-Disposition': 'attachment; filename="sample.png"',
'Content-Type': 'image/png'
},
data
);
// アップロード成功時のレスポンス
console.log(resp);
} catch (error) {
console.error(error);
}
})();
今回は fetch で解決しましたが、もし今後kintone.proxy経由でファイルを扱う必要がある場合は、こちらの kintone.proxy.uploadを試すのがベストプラクティスかもしれません。