AWSのS3でパス形式でのAPIリクエストが使えなくなる事への対応策

先日、Amazonから「Amazon S3は、2020年9月30日以降、パス形式のAPIリクエストをサポートしなくなります」と発表がありました。
Amazonの記事はこちら

概要

もともとS3には2種類のAPIリクエスト方法があります。

1つはパス形式。(V1とも呼ばれます)
パス部分にバケット名が入っており、2020年9月30日以降使えなくなる方式です。(ただし、2020年9月30日以前に作られたバケットは変わらず使えるとのこと)

もう1つは仮想ホスト形式。(V2とも呼ばれます)
ホスト部分にバケット名が入っており、こちらは今後も使える方式です。

パス形式の方が親しみがあるかと思いますが、今後は必ず仮想ホスト形式を使ってくださいということらしいので、対応策を考えました。

対応策

あくまで新しく始める開発を前提としています。開発済みのシステムなどの対応をする場合は、画像パスの置き換えなどで対応できると思います。

今回はphp開発でよく使うLaravelを例にしました。

環境

Laravel:5.6
MySQL:5.7

やったこと

今後、再度API仕様が変わらないとも限らないので、その場合にも対応しやすい方法で実装しました。
やっていること自体は簡単で、ホスト部分をenvファイルで共通化してしまおうといったものです。

使用するファイルは以下の想定です。
http://<bucket-name>.s3-ap-northeast-1.amazonaws.com/media/test.jpg

画像パスを格納するカラムを「img_path」とします。
「img_path」にはパス部分のみの「/media/test.jpg」を格納します。

envファイルには以下の一行を加えます。
<buket-name>は自分の環境に合わせてください。

画像を使いたい画面のbladeファイルは以下。
$img_pathには「img_path」カラムの中身が入っている想定です。

これでパスより前の部分がもし変わっても、変更する部分はenvファイルのみになるので管理が簡単です。

まとめ

今までDBには画像パス全部入れるのが当たり前と考えていましたが、今回のようなAWSの急な変更などには対応しづらいと思いました。
共通化できる部分は共通化していくことで、管理が楽になるのだと改めて実感すると同時に、今後同じようなことが起きることを想定して実装を進めるのが大切だと感じました。

 

システム開発のご相談はこちらからお気軽にお問合せください。


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です