API Routes にタスク処理リクエスト用のエンドポイントを実装する

[kuniyuki-f]

issueURL

101

この PR で対応する範囲 / この PR で対応しない範囲

• API Routes に createTask, stopTask のエンドポイントを実装する
• 上記エンドポイント経由でクライアントコンポーネントからバックエンドにリクエストする処理を実装する
• 一旦、実装方針を固めるために「動的パスパラメータを含む・含まないエンドポイント及びリクエスト」の2パターンの処理を実装する。
  • この2パターンの実装を基にその他のエンドポイント実装するため、本 PR ではその他のエンドポイントに関する処理は実装せず、別 PR で対応する。

Storybook の URL、 スクリーンショット

リクエスト処理の実装なのでスクショはありません。

変更点概要

• src/api/client/fetch/task.ts の実装 クライアントコンポーネントから呼び出す、API Routes 向けのリクエスト処理を実装します
• API Routes ( src/pages/api ) の実装 フロントエンドからバックエンドに API リクエストを送信するための中継用エンドポイントを実装します

レビュアーに重点的にチェックして欲しい点

以下の処理を１つずつ実装してみました。

• 動的なパスパラメータを含むリクエスト処理（ stopTask ）
• 動的なパスパラメータは含まないリクエスト処理 ( createTask )

それぞれ、ソースコードにチェックしてほしい点をコメントします。 上記2点の実装が問題なさそうであれば、マージしてその他の API Routes の実装も行おうと思います。

Note 本 PR 作成当初、動的なパスパラメータを含むリクエスト処理 ( stopTask ) については API Rotues 上でも動的ルーティングの形を取っていました ( 8424587f402a232b7296c18492469ac2231b3ea1 , d6b71b89ed838e047c99a3e4f5385562073e47f0 )。 しかし、API Routes上での動的ルーティングを廃止し、クライアントコンポーネントから API Routes へのリクエストを送信する際のパラメータは全てリクエストボディに含めるようにしました ( dbab97a369c8d306f4c3a3902d1ac190b6e8549e ) 。 結果的に、動的パスパラメータの有無による差異はあまりなくなりました🙏

上記Noteのような方針を取った理由は以下のとおりです

• 動的ルーティングのパスパラメータ（ req.query ）は全ての値が Optional で型定義する必要があり、処理が煩雑になること
• バックエンドへの中継用の API エンドポイントで動的ルーティングを行うメリットがないこと
  → リクエストボディでパラメータを受け取り、dto をsrc/api/server/fetch/task.tsのメソッドに渡せば問題ないため

補足情報

とくになし

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
timelogger-web	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Aug 14, 2023 7:47am