느리게 만들기 및 오류 코드 추가 - C# 코스에서 샘플 API 빌드하기

샘플 API 소개 및 목적

팀은 웹 개발을 배울 때 샘플 API를 활용하는 것이 얼마나 중요한지 다시 한번 강조하며 강의를 시작합니다. 이러한 API는 프런트엔드 애플리케이션을 테스트할 수 있는 구체적인 기준을 제공합니다.

팀은 이 과정을 마칠 때쯤 다음과 같은 기능을 포함하는 견고한 API를 구축하는 것을 목표로 합니다.

• 샘플 데이터

• 문서화

• 건강 검진

• 시뮬레이션된 속도 저하

• 모의 오류

• Docker 및 VPS를 통한 배포 옵션

이번 강의에서 Tim은 불리한 조건에서 실제 API 동작을 시뮬레이션하고 오류 코드를 생성하여 속도 저하를 방지하는 데 중점을 둡니다.

API 엔드포인트에 인위적인 지연 시간 추가하기

팀은 특정 API 엔드포인트, 특히 코스 데이터와 관련된 엔드포인트에 선택적 지연 매개변수를 추가하는 것으로 시작합니다. 그의 목표는 프런트엔드 테스트를 개선하기 위해 느린 API 응답을 시뮬레이션하는 것입니다.

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

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

지연 메커니즘 테스트

팀은 Postman(또는 Postman 복제 프로그램)을 사용하여 몇 가지 테스트를 실행하여 지연 논리를 검증합니다. 예를 들어:

• delay=5000(5초)은 API가 결과를 반환하기 전에 잠시 멈추도록 합니다.

• delay=500으로 설정하면 일시 정지 시간이 짧아집니다.

그는 실제 지연 시간은 처리 오버헤드 때문에 지정된 값보다 항상 약간 더 길어질 것이라는 점을 지적하는데, 이는 현실적인 측면에서 중요한 미묘한 차이입니다. 팀이 5분 9초 에 언급했듯이, API 호출 시간을 밀리초 단위까지 정확하게 측정하는 것이 아니라 임계값을 시뮬레이션하는 것입니다.

지연 기능 확장을 더 많은 엔드포인트에 적용

Tim은 단순히 "모든 강좌 불러오기" 엔드포인트에만 머무르지 않습니다. 그는 일관성을 원하기 때문에 "ID로 코스 불러오기" 엔드포인트에 동일한 지연 기능을 구현합니다.

6시 15분에 그는 문제에 부딪혔습니다. 비동기식으로 변환할 때 메서드 이름에 자동으로 "Async"가 추가되면서 이름 충돌이 발생한 것입니다. Tim은 명확성과 일관성을 위해 두 메서드 이름을 비동기 명명 규칙에 맞게 조정했습니다.

테스트를 통해 구현이 확인되었습니다.

• 지연 사항은 존중됩니다.

• 존재하지 않는 레코드는 지연 후 예상대로 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은 "잘못된 요청"을 반환합니다.

• 401 오류는 "권한 없음"을 반환합니다.

• 404는 "찾을 수 없음"을 반환합니다.

• 301번은 "영구 이동됨"을 반환합니다.

• 405 오류는 "허용되지 않는 메서드"를 반환합니다.

이는 엔드포인트의 유연성을 보여줍니다. 오류 코드뿐만 아니라 모든 HTTP 상태 코드에 대해 작동합니다. 오후 1시 4분에 Tim은 이 접근 방식이 프런트엔드 앱이 다양한 서버 응답을 처리하는 방식을 테스트하는 데 이상적이라고 확인했습니다.

그는 이름을 /httpcode로 지을까 고려했지만, 주로 오류 상황을 시뮬레이션하는 데 사용되기 때문에 간편함을 위해 /error라는 이름을 그대로 사용하기로 했습니다.

기능 개선 사항 요약

팀은 영상 말미에 API 개선 사항을 요약하며 마무리합니다.

• 속도 저하는 API 응답에서 발생하는 실제 지연 시간을 시뮬레이션합니다.

• 오류 시뮬레이션은 사실상 모든 HTTP 응답에 대해 테스트할 수 있는 유연성을 제공합니다.

• 이러한 기능 덕분에 샘플 API는 더욱 강력해지고 실제 테스트 시나리오에 매우 유용하게 활용될 수 있습니다.

14시 16분에 Tim은 지연된 응답이나 다양한 서버 오류와 같은 여러 API 상태에서 앱이 어떻게 작동하는지 테스트하는 데 이러한 도구가 얼마나 중요한지 강조합니다.

다음 단계: API를 Docker화하기

이 영상에서 자세히 다루지는 않았지만, Tim은 다음 단계로 API를 Dockerize하는 것을 암시했습니다. 이를 통해 개발자는 샘플 API를 자체 포함된 Docker 컨테이너에서 로컬로 실행할 수 있으므로 다양한 환경에 배포하고 공유하는 것이 더 쉬워집니다.

마지막으로

팀은 영상 말미에서 개발자들이 실제로 테스트해야 할 현실적인 기능을 포함하는 포괄적인 샘플 API를 구축하겠다는 자신의 의지를 재차 강조합니다. 이러한 기능에는 다음이 포함됩니다.

• 지연

• 오류

• 건강 검진

• 인증 및 고급 엔드포인트에 대한 향후 계획

목표는 간단하지만 강력합니다. 개발자에게 실제 API의 특성을 모방하는 도구를 제공하여 애플리케이션이 견고하고 안정적이며 사용자 친화적이도록 하는 것입니다.

결론

이 강의를 마치면 시청자들은 API에 인위적인 지연과 오류 응답을 도입하는 방법과 이유에 대해 더 잘 이해하게 될 것입니다. 팀 코리의 접근 방식은 체계적이고 실용적이며 실제 애플리케이션 테스트 요구 사항과 직접적으로 연결되어 있습니다. API 테스트 역량을 강화하고 싶다면 이 강의는 훌륭한 자료가 될 것이며, 이제 어디서 정보를 찾아야 할지 정확히 알게 되셨습니다.

팀 코리의 전체 비디오 강의를 시청하여 실습 지침을 확인하세요.