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の集客力の影響？