<ol><li>1xx (情報): リクエストが受信され、継続して処理されることを示す。</li><li>2xx (成功): リクエストが正常に受信、理解、処理されたことを示す。</li><li>3xx (リダイレクト): リクエストを完了するために、さらなるアクションが必要であることを示す。</li><li>4xx (クライアントエラー): クライアントが悪いリクエストを送信したか、リクエストを処理できないことを示す。</li><li>5xx (サーバーエラー): サーバーが正しいリクエストを処理できなかったことを示す。</li></ol><p>以下に、よく使われるいくつかのHTTPステータスコードとその意味を示します。</p><ul><li>200 OK: リクエストが成功し、サーバーが要求されたデータを返しています。</li><li>201 Created: リクエストが成功し、サーバーが新しいリソースを作成しました。</li><li>204 No Content: リクエストが成功し、サーバーが返すべきデータがないことを示します（例：DELETEリクエスト）。</li><li>400 Bad Request: クライアントが不正または不完全なリクエストを送信しました。</li><li>401 Unauthorized: クライアントが認証されていないため、リクエストにアクセスできません。</li><li>403 Forbidden: クライアントが認証されていても、リクエストされたリソースへのアクセスが許可されていません。</li><li>404 Not Found: リクエストされたリソースが見つからなかったことを示します。</li><li>500 Internal Server Error: サーバー側でエラーが発生しました。</li></ul><p><br></p>

エラーコードメモ

<h2 id="he313374e63">. JWTトークンとは</h2><p>JSON Web Token（JWT）は、クライアントとサーバー間で情報を安全にやり取りするためのコンパクトなトークン形式です。JWTは、ヘッダー、ペイロード、署名の3つの部分から構成されており、それぞれBase64Urlエンコードされた文字列で表現されます。JWTは、認証や認可に広く使われています。</p><h3 id="h9cb6bb63af">JWTトークンを使用したログイン機能の使用例</h3><ol><li>クライアントがユーザー名とパスワードをサーバーに送信します。</li><li>サーバーがユーザーの認証を行い、認証に成功した場合、JWTトークンを生成してクライアントに返します。</li><li>クライアントは、以降のリクエストにJWTトークンをAuthorizationヘッダーに含めて送信します。</li><li>サーバーは、JWTトークンを検証し、有効な場合はリクエストを処理します。</li></ol><h2 id="h578388db81">2. サーバーセッションとは</h2><p>サーバーセッションは、サーバー側でユーザー情報や状態を一時的に保存する仕組みです。セッションIDを用いてクライアントとサーバー間でセッションを識別し、認証や認可に利用されます。</p><h3 id="h0dc344fc56">サーバーセッションを使用したログイン機能の使用例</h3><ol><li>クライアントがユーザー名とパスワードをサーバーに送信します。</li><li>サーバーがユーザーの認証を行い、認証に成功した場合、セッションIDを生成し、クライアントに返します。</li><li>クライアントは、以降のリクエストにセッションIDをCookieに含めて送信します。</li><li>サーバーは、セッションIDをもとにセッション情報を取得し、有効な場合はリクエストを処理します。</li></ol><h2 id="hfe3e8a8438">3. JWTトークンとサーバーセッションの違い</h2><ul><li>ストレージ: JWTトークンはクライアント側で保持され、サーバーセッションはサーバー側で保持されます。</li><li>スケーラビリティ: JWTトークンはステートレスなので、複数のサーバー間で共有する必要がありません。一方、サーバーセッションはセッション情報をサーバー側で保持するため、スケーラビリティが低いです。</li></ul><h2 id="hb74adf9978">4. メリットとデメリットの比較</h2><h3 id="hc859d85541">JWTトークン</h3><p>メリット:</p><ul><li>ステートレス: サーバーがユーザー情報を保持する必要がないため、スケーラビリティが高い。</li><li>SPAに適している: クライアント側でトークンを管理するため、サーバーとの通信が簡単になる。</li></ul><p>デメリット:</p><ul><li>セキュリティ: クライアントに情報が保持されるため、トークンの漏洩リスクが高い。</li><li>トークンサイズ: ペイロードに情報を持つため、トークンサイズが大きくなる可能性がある。</li></ul><h3 id="h38c8ca91f6">サーバーセッション</h3><p>メリット:</p><ul><li>セキュリティ: セッション情報がサーバー側に保持されるため、情報漏洩のリスクが低い。</li><li>トークンサイズ: セッションIDのみをクライアントとやり取りするため、通信量が少ない。</li></ul><p>デメリット:</p><ul><li>スケーラビリティ: セッション情報をサーバー側で管理するため、スケーラビリティが低い。</li><li>セッション管理: セッション情報の有効期限管理やサーバー間での共有が必要になる。</li></ul><h2 id="h97ed3e39ff">5. JWTがSPAで使用される理由</h2><p>JWTは、ステートレスであるため、スケーラビリティが高く、サーバーの負荷を軽減できます。また、SPAではフロントエンドとバックエンドが分離されているため、クライアント側でトークンを管理するJWTが適しています。これにより、APIリクエスト時に簡単に認証情報を付与でき、バックエンドの処理もシンプルになります。<br>ただし、JWTを使用する場合は、トークンのセキュリティ対策が重要です。</p><h2 id="hda3eb2d590">6. Next.jsのSSRやSSGでの適用</h2><p>Next.jsは、Reactベースのフレームワークで、Server-Side Rendering（SSR）やStatic Site Generation（SSG）をサポートしています。これらのアプローチを用いる場合、JWTトークンとサーバーセッションのどちらが適しているかを検討します。</p><h3 id="h33fd868b2f">SSR（Server-Side Rendering）</h3><p>SSRでは、各リクエストごとにサーバーでHTMLを生成してクライアントに送信するため、サーバー側でユーザー情報や認証情報を処理することが容易です。このため、サーバーセッションを用いた認証が適しています。ただし、JWTトークンも使用可能で、リクエストヘッダーやCookieを通じてサーバーに送信することで、サーバー側でトークンを検証して認証を行うことができます。</p><h3 id="h410720dce9">SSG（Static Site Generation）</h3><p>SSGでは、ビルド時に静的なHTMLファイルを生成するため、リクエストごとにサーバーでHTMLを生成する必要がありません。このため、クライアント側での認証処理が主になり、JWTトークンを使用した認証が適しています。一方で、サーバーセッションを用いた認証は、リクエストごとにサーバーとの通信が発生するため、SSGの恩恵が少なくなる可能性があります。<br></p>

JWTトークンとサーバーセッションによるログイン機能の違いと使用例

<h2 id="h3183ebf097">1. Nest.jsとは</h2><p>Nest.jsは、効率的でスケーラブルなサーバーサイドアプリケーションを構築するためのNode.jsフレームワークです。Angularにインスパイアされた構造を持ち、モジュール性、テストの容易さ、保守性に重点を置いています。また、TypeScriptを使用して書かれており、型安全とオブジェクト指向プログラミングをサポートしています。</p><h2 id="h29ce30b628">2. TypeScriptとNest.js</h2><p>Nest.jsはTypeScriptをベースにしているため、開発者は型安全とオブジェクト指向プログラミングの利点を享受できます。TypeScriptはJavaScriptのスーパーセットであり、静的型付けやインターフェイスを提供し、開発者の生産性を向上させます。</p><h2 id="h8269fcd22a">3. モジュール、サービス、コントローラーについて</h2><p>Nest.jsアプリケーションは、モジュール、サービス、コントローラーという3つの主要な要素で構成されています。</p><ul><li>モジュール: アプリケーションの機能をカプセル化し、再利用可能なコードを提供するための仕組みです。モジュールは、アプリケーション内の関連するサービスやコントローラーをグループ化します。</li><li>サービス: ビジネスロジックやデータアクセスを担当し、アプリケーションの機能を実装するためのクラスです。サービスは、コントローラーから呼び出され、データベースや外部APIとの通信を行います。</li><li>コントローラー: クライアントからのリクエストを処理し、適切なサービスに処理を委譲します。また、サービスからのデータをクライアントに返す役割も担当します。</li></ul><h2 id="hce63efcd0e">4. DTO (Data Transfer Object)</h2><p>DTO（Data Transfer Object）は、クライアントとサーバー間でデータをやり取りする際に使用されるオブジェクトです。Nest.jsでは、DTOを使ってAPIのリクエストとレスポンスのデータ構造を定義し、型安全を確保します。DTOはTypeScriptのインターフェイスやクラスを使用して定義されます。<br>DTOを使用することで、APIのリクエストとレスポンスのデータ構造を明確にし、エンドポイントの仕様を簡単に理解できるようになります。また、型の不一致や不正なデータによるバグを防ぐことができます。<br></p><h2 id="heb499575c8">5. PipeとValidationPipeによるバリデーション</h2><p>Nest.jsでは、Pipeという機能を利用して、リクエストデータの変換やバリデーションを行うことができます。Pipeは、リクエストデータを受け取り、それを変換したり、条件に従って検証したりする処理を行います。<br>ValidationPipeは、Nest.jsが提供するビルトインPipeの一つで、DTOによって定義されたデータ構造に基づいてリクエストデータのバリデーションを行います。ValidationPipeは、通常、class-validatorとclass-transformerという2つのライブラリと連携して動作し、データの型変換や検証ルールの適用を行います。<br>コントローラーのメソッドにValidationPipeを適用することで、CreateUserDtoに基づいたリクエストデータのバリデーションが行われます。<br>これにより、リクエストデータがDTOの定義に沿っていない場合、自動的にエラーが返され、開発者はバリデーションのためのコードを省略することができます。<br></p>

HIROBLOG

Nest

エラーコードメモ

JWTトークンとサーバーセッションによるログイン機能の違いと使用例

Nest.jsとは何か