スローダウンとエラーコードの追加 - C#でサンプルAPIを構築するコース

サンプルAPIの紹介とその目的

Timはレッスンの冒頭で、Web開発を学ぶ際にサンプルAPIを持つことの価値を繰り返し説明します。 このようなAPIは、あなたのフロントエンド・アプリケーションをテストするための具体的な何かを与えてくれます。

コース終了までに、Timは以下を含む堅牢なAPIを構築することを目指しています：

• サンプルデータ

• ドキュメンテーション

• ヘルスチェック

• 速度低下のシミュレーション

• 模擬エラー

• DockerとVPSによるデプロイメントオプション

この具体的なレッスンでは、Timは、速度低下のシミュレーションと、悪条件下での現実的なAPIの動作のためのエラーコードの生成に重点を置いています。

APIエンドポイントに人工的な遅延を追加する

Timは、特定のAPIエンドポイント、特にコースデータを扱うAPIエンドポイントに、オプションのdelayパラメータを追加することから始めます。 彼の目標は、より良いフロントエンドのテストのために、遅いAPI応答をシミュレートすることです。

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

遅延メカニズムをテストする

TimはPostman（またはPostmanのクローン）を使っていくつかのテストを実行し、遅延ロジックを検証します。 例えば：

• delay=5000（5秒）は、結果を返す前にAPIを一時停止させます。

• delay=500にすると、間が短くなります。

彼は、実際の遅延は、処理のオーバーヘッドにより、指定された値よりも常にわずかに長くなることを観察しています。 Timが5:09で述べているように、APIをミリ秒単位でタイミングをとるのではなく、閾値をシミュレートするのです。

遅延機能をより多くのエンドポイントに拡張する

ティムは、"すべてのコースを読み込む"エンドポイントだけにとどまりません。 彼は一貫性を望んでいるので、"load course by ID "エンドポイントに同じ遅延機能を実装します。

6:15で、非同期への変換時にメソッド名に"Async"が自動的に追加されることによる命名の衝突という問題にぶつかります。 Timは、両方のメソッド名をAsync命名規則に合わせて調整し、明快さと一貫性を保っています。

テストで実装を確認します：

• 納期は厳守します。

• 存在しないレコードは、遅延後に期待どおりに404を返します。

• 遅延の削除や空の値の受け渡しは適切に動作し、TimはAPI自体の問題ではなく、PostmanのUIの癖を指摘している（8:00）。

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

エラー エンドポイントのテスト

Tim は今、さまざまなステータス・コードを渡してエラー・エンドポイントをテストしています：

• 400 は "Bad Request" を返します。

• 401 は "Unauthorized" を返します。

• 404 は "Not Found" を返します。

• 301 は "Moved Permanently" を返します。

• 405 は "Method Not Allowed" を返します。

これは、エラーコードだけでなく、あらゆるHTTPステータスコードに対するエンドポイントの柔軟性を示しています。 13:04で、Timはこのアプローチがフロントエンドアプリが異なるサーバーレスポンスをどのように扱うかをテストするのに理想的であることを確認しています。

彼は/httpcodeという名前も考えたが、主にエラー状態をシミュレートするために使用されるため、シンプルに/errorにこだわった。

機能強化の概要

ティムは、APIに加えられた改善点を要約してビデオを締めくくります：

• スローダウンは、APIレスポンスにおける現実世界の待ち時間をシミュレートします。

• エラーシミュレーションは、事実上どんなHTTPレスポンスに対してもテストできる柔軟性を提供します。

• これらの機能により、サンプルAPIはより堅牢になり、現実的なテストシナリオにとって貴重なものとなります。

14:16で、Timは、遅延応答やさまざまなサーバーエラーなど、さまざまなAPIの状態下でアプリがどのように動作するかをテストするための、これらのツールの重要性を強調しています。

次へ：APIをドッキングする

このビデオでは詳しく説明されていませんが、ティムは次のステップを示唆しています：APIをDocker化する。 これにより、開発者は自己完結型のDockerコンテナでサンプルAPIをローカルに実行することができ、異なる環境でのデプロイや共有が容易になります。

最終的な考え

Timは、開発者が実際にテストする必要のある現実的な機能を含む包括的なサンプルAPIを構築することへのコミットメントを繰り返し、ビデオを締めくくります。これには以下が含まれる：

• 遅延

• エラー

• ヘルスチェック

• 認証と高度なエンドポイントに関する今後の計画

目標はシンプルですが、強力です。実際のAPIの癖を模倣したツールを開発者に提供することで、アプリケーションを堅牢で、信頼性が高く、ユーザーフレンドリーにすることです。

結論

このレッスンが終わるころには、視聴者はAPIに人為的な遅延やエラー応答を導入する方法と理由をよりよく理解できるようになっています。ティム・コーリーのアプローチは理路整然としており、実践的で、実際のアプリケーションテストのニーズに直接結びついています。 APIテストを強化したいのであれば、このレッスンは優れたリソースです。

ティム・コーリーによるビデオレッスンで、実践的なガイダンスをご覧ください。