ODCのConsume REST APIを使ってQiita APIを呼び、自分の記事の閲覧数を取得してみる。
実現イメージ
操作としては、以下の機能を実現する。
- 画面を開くと、Qiita APIで直近100件分の記事データを取得して表示
- 取得済みの記事数＜総記事数のとき「次のページを取得」ボタンを表示。クリックすると次の100件を取得してテーブルの最後に追加
- 必要なだけデータを取得し終わったら「Excelダウンロード」をクリックしてExcelファイルとして取得
Qiita APIの検討
以下のドキュメントを参照する。
アクセストークン
APIの種類によって認証・認可が必要なものと不要なものがある。
また、同じAPIでも認証・認可されているか否かでレートリミットが異なってくる。
利用制限
認証している状態ではユーザーごとに1時間に1000回まで、認証していない状態ではIPアドレスごとに1時間に60回までリクエストを受け付けます。
使用するAPI
このAPIが良さそう。アクセストークンで認証したユーザーが書いた記事の一覧を取得できる。
GET /api/v2/authenticated_user/items
認証中のユーザーの記事の一覧を作成日時の降順で返します。
（「GET /api/v2/users/:user_id/items」という似たようなAPIもあるが、「"page_views_count"」項目の値がnullで返ってきたので断念した）
このAPIはページングをするため、以下のようにpage（ページ番号）とper_page（ページサイズ）をクエリストリングとして渡す。
/api/v2/authenticated_user/items?page=1&per_page=20
APIの性質を検討
以下の通り、OutSystemsのConsume REST APIで問題なくアクセスできそう。
- Content-Type: application/json
- ステータスコードは「GETまたはPATCHリクエストに対しては200を」返す
- エラー時は他のステータスコードを取りうる、またエラー時は違うレスポンスフォーマット。今回はテストなのでこの部分は無視しておく
アクセストークンを取得する
以下の手順で自分のユーザー用のアクセストークンを取得する。同じトークンを再確認できないので発行したら確実に保管しておく。
Qiitaにログインし、以下のページにアクセス。
「新しくトークンを発行する」をクリック。
スコープでは今回必要な「read_qiita」のみをチェックして「発行する」ボタンをクリック。次の画面で表示されるトークンを保存しておく。
Consume REST API
今回は単独のAPIが対象で、swagger.jsonも見当たらなかったので、RESTを右クリック → Consume REST API..を選択し、Add single methodのオプションを選択して作成する。
URL
まず、使うAPIのI/Fが「GET /api/v2/authenticated_user/items」であるから、メソッドはGETを選択する。
ドメイン名はqiita.comを使う。またAPIのパラメータとしてpageとper_pageが必要なので、URLは
https://qiita.com/api/v2/authenticated_user/items?page={Page}&per_page={Per_Page}
となる。{}で囲んでいる部分は、REST API MethodのInput Parameterにするべき部分を指定する書き方。この書き方だと、Input Parameterとして「Page」と「Per_Page」が作成される。
Headersタブ
このAPIには認証されたユーザーを特定するため、リクエストヘッダーに「Authorization」を渡さないといけない。
また、ページングのために、認証されたユーザーの総記事数が欲しいので、レスポンスヘッダーにある「Total-Count」を取得する。
上記の設定を行うには、ダイアログ中でHeadersタブを選択し、以下のように入力する。
なお、レスポンスヘッダーには、ページング用のリンクが含まれているので、これを使ってページングする方法もありうるが、OutSystemsのロジックからは若干使いにくかったので自前でページングすることにした。
テスト実行してレスポンスフォーマットを取得
Testタブを開き、各パラメータに以下のテスト値を入力してTestボタンをクリック
- Page: 1 (1ページ目）
- Per_Page: 30（1ページあたり30件）
- Authorization: Bearer <アクセストークン>
(<アクセストークン>部分は実際の値に置き換える）
APIのレスポンスがResponse test resultに表示されるのでボディ（JSONの部分）をBodyタブにコピーする（一番下にCopy to response bodyボタンがあるのでそれをクリックすればよい）。
ここまでできたらFinishボタンをクリック。
APIのレスポンスを画面表示用に詰め替えるStructure
どの記事かを示す属性と、目的の記事の閲覧数を示す属性を抜き出すStructure QiitaArticleを定義する。
（左がAPIのResponse、右が定義するStructure。赤枠で囲った属性をそのままStructureにコピーするが、TagItemsだけはListであるため、いったんStructureにコピーした後ロジックで結合し、結果をTagsJoined属性に設定することにする）
画面とロジック
画面イメージは「実現イメージ」のセクション参照。
アクセストークンはSettingで保持
アクセストークンはセキュアに保つべき情報なので、Is secret=Yesに設定する。この場合、必ずODC Portalで値を設定しないといけない。
Data Action
Data ActionでAPIを呼び出す（Bearerの後にスペースが入っている点に注意）。
ページサイズは固定で100とし、ScreenのLocal Variableで現在のページ数をCurrentPageとして保持している。
CurrentPageは初期値1とする（画面初期表示時に最初の1ページを取得する）。
On After Fetch
やることは2つ。
- APIのOutput Parameter TotalCountで最大の記事数がわかるので、記事数から最大のページ数を計算する (今回の例だと218件の記事があったので最大のページ数は3）
- Data ActionのOutput Parameterを、StructureのList（画面のLocal Variable）に詰め替える。同時にTagItemsをTagsJoinedに設定
次のページボタン
クリックすると、Data ActionをRefresh Dataする。
現在のページ < 最大のページ数のときのみクリック可能にする。
Excelエクスポートボタン
StructureのList（画面のLocal Variable）をRecordListToExcelでExcelファイルに変換し、ダウンロードさせる。
ちなみに
こんな感じのExcelが取れた。
自分でQiitaに書いた記事は、2024/8/15時点で
- 218記事
- 一番古い記事は2019/1/1
- 総ページビューは707222
- 最もページビューが多かった記事は、2019/10/8に書いた「(OutSystems)Reactive Web AppとTraditional Webの違い」で19536
意外とページビューがあった。Qiitaの集客力の影響？