GASのウェブアプリのURLは一般公開して問題ないか?
課題感
Google Apps Script(GAS)で、スプレッドシートのデータをjsonとして返すAPIを公開したい。
GASはウェブアプリとしてデプロイすることでURLが発行される。
なんかこのままJSでフロントから呼んで良いっぽい感じはするが、リダイレクトされて ?user_content_key=****
というパラメータがつく。
これがSECRET_KEYっぽいというか、秘匿すべき値にも一見みえる。このパラメータの意味はなんなんだ??という。
一般公開しているサイトを見かけるし、秘匿せよと書いてあるわけでもないし、公開前提でいろいろ書かれているようにも思えるので問題ないだろうが、なんとなく不安がある。
このぼんやりとした不安感を解消したいというのが課題。
GASの関連用語
まずは地固めとして、ふわっと使っている用語を整理してみる。
デプロイ
Apps Script プロジェクトのデプロイは、ウェブアプリ、アドオン、API 実行可能ファイルとして使用できるスクリプトのバージョンです。デプロイを作成および管理することで、コードの反復処理、変更の追跡、ユーザーがアクセスできるコードの正確なバージョンの管理が可能になります。
- デプロイには次の 2 種類があります。
- ヘッドデプロイ。常に現在のプロジェクト コードに同期されます。
バージョニングされたデプロイ。特定のプロジェクト バージョンに接続されます。
いわゆるデプロイと同等の意味とも言えるが、より版を意識できるかたち
ヘッドデプロイ
ヘッドデプロイは、現在のプロジェクト コードです。Apps Script プロジェクトを作成すると、そのプロジェクトのヘッドデプロイが自動的に作成されます。
ヘッドデプロイは、最近保存されたコードと常に同期されています。たとえば、バージョニングされたデプロイを作成してコードを変更した場合、ヘッドデプロイにはその変更が反映されますが、バージョニングされたデプロイはそのまま残ります。
ヘッドデプロイを使用してコードをテストします。一般公開でヘッドデプロイを使用しないでください。
最新のコードと常に同期しているとのことだが、それってどこから見れるんだろう。
本筋ではないので一旦保留。
バージョンつきデプロイ
バージョニングされたデプロイでは、特定のバージョンのプロジェクト コードを使用できます。これにより、コードの変更や改善を行う間、ユーザーは有効なバージョンを引き続き使用できます。
アプリケーションを公開して公開する場合は、常にバージョニングされたデプロイを使用します。一度に複数のアクティブなデプロイ バージョンを持つことができます。
重要: バージョニングされたデプロイのオーナー権限を譲渡することはできません。スクリプト プロジェクトの所有権を他のユーザーに譲渡する場合、プロジェクト内の既存のバージョニングされたデプロイの所有者は変更されません。管理者がデプロイメント オーナーのアカウントを削除すると、デプロイメントのスクリプト エラーが発生することがあります。
バージョニングをちゃんとしろよという話。
JSON返すときJSONの構造変わったりしたら困りますからね。 /v1/
みたいなもんかな。
- ウェブアプリ
- 実行可能API
- アドオン
- ライブラリ
この辺の差がよくわからないな
APIのリミットがあるとはよく聞くが、具体的な制限はどこに書いてあるのか?
ウェブアプリ
スタンドアロン スクリプトとアプリケーションにバインドされているスクリプトはいずれも、下記の要件を満たしていれば、ウェブアプリに変換できます。
- doGet(e) または doPost(e) 関数が含まれています。
- この関数は、HTML サービス HtmlOutput オブジェクトまたは コンテンツ サービス TextOutput オブジェクトを返します。
前者はdoGet/doPostを用意せよってことで分かるが、後者が何言ってるのかわからない
コンテンツサービス
function doGet() {
return ContentService.createTextOutput('Hello, world!');
}
doGet/doPostで ContentService()
を返却せよということか
ウェブページでの JSONP の配信
わずかな変更により、JSON サービスは JSONP になる場合があります。つまり、ブラウザで JavaScript から呼び出すことができます。新しいスクリプトは次のとおりです。
JSONPである必要はないけど、こういう記述がある以上、サーバーを経由させたりせずに公開される前提と考えていいな
リダイレクト
セキュリティ上の理由から、コンテンツ サービスから返されたコンテンツは script.google.com から提供されず、script.googleusercontent.com の 1 回限りの URL にリダイレクトされます。つまり、コンテンツ サービスを使用して別のアプリケーションにデータを返す場合は、リダイレクトに従うように HTTP クライアントを構成する必要があります。たとえば、cURL コマンドライン ユーティリティで、フラグ -L を追加します。この動作を有効にする方法の詳細については、HTTP クライアントのドキュメントをご覧ください。
リダイレクト前の script.google.com
ドメインのURLを使ってことかな
不安についてはほぼ解消できたので、API制限について調べる。
これがすべてだが、自分にとって大事そうなものを抜いてみる。
ランタイム:6分/実行
1回実行して処理が完了するまで6分を超えると終了される。スクレイピングで記事一覧を取得、そこから個別の記事の情報をxx件取得して・・・みたいなことやってたら超えそうではある。
カスタム関数のランタイム: 30 秒 / 実行
1つの関数の処理時間かな。
doGetとかはカスタム関数ではないだろうけど、関数のネストがどういう扱いになってるのかは気になる。
同時実行 30 / ユーザー
厳しい。一般公開するプロダクトはもちろん、学校のクラスやら、結婚式の出し物やら、30人でせーの!ってやったらエラー返ってくるのか。
リクエスト頻度の制限が明記されていないのは以外だったが、処理完了まで遅いし、同時実行の制約が自分の中では新たな課題。