Written on
·
47
0
안녕하세요, 권철민 강사님.
FastAPI로 실제 서비스를 운영 중인 주니어 개발자입니다.
EmailStr이나 max_length=40 같은 경우, 프론트엔드에서 입력을 제한하더라도 백엔드에서 예외 처리를 한다고 가정할 때, Pydantic의 검증 오류는 모두 422 에러로 반환됩니다.
이 경우, 클라이언트에서 특정 오류(예: 이메일 형식 오류, 최대 길이 초과 등)를 구분하기 어려운 문제가 있습니다.
클라이언트에서 특정 오류에 대해 모달을 띄우는 등의 처리가 필요할 때, Pydantic 검증 대신 비즈니스 로직에서 200 응답을 반환하고, 약속된 에러 코드를 통해 오류를 구분하는 방식이 적절할까요?
정답은 없지만 어떻게 처리하는게 맞을까요?
Answer 2
0
안녕하십니까,
질문을 제대로 이해했는지 잘 모르겠습니다만, Pydantic으로 Form Validation 적용 시 검증 오류가 발생할 때 422 Status 와 Json 형식으로 일괄 오류 메시지 출력이 되는 것을 Custom 오류 메시지로 변경하시는 것을 원하시는 걸로 간주하고 말씀드리겠습니다.
섹션 14를 보시면 FastAPI Exception Handler 섹션이 있습니다. 해당 섹션에는 Custom Error Handling을 어떻게 수행하며, Pydantic 검증 오류인 RequestValidationError를 어떻게 Custom Error 로 변환하는지에 대한 내용이 수록되었습니다.
먼저 해당 강의를 들으시고, 원하시는 부분이 아니면 다시 글 부탁드립니다
추가적으로, Exception Handler 강의에서도 말씀드리는데 Pydantic과 FastAPI가 너무 강하게(?) 결합되어 있어서 세부적인 검증 오류별로 오류 메시지를 구분하여 출력하기가 어려운 부분이 있습니다.
예를 들어 고객 정보 Form에서 email 체크와 이름 문자열 길이 체크와 같은 validation들이 있다고 할때 Form 에서 email 체크와 문자열 길이 체크 중에 뭔가 잘못되면 Custom Error Message Handler를 이용하여 Custom 메시지를 만들어 낼수 있습니다. 근데 정확하게 email 체크가 문제인지, 문자열 길이 체크가 문제인지를 찾아서 정확한 오류 메시지를 custom message에 담아 주려면 RequestValidationError의 Json message를 Parsing해서 원하는 부분 매핑을 시켜준 다음에 Custom Error Message를 만들어 줘야 합니다. 해당 부분은 제가 강의에서 수록하지는 않았지만, 강의를 들으신다면 어떻게 해야 할지 감이 오실겁니다.
먼저 강의를 들으시고, 더 필요하시면 다시 질문 부탁드립니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
BH J님께서 질문하신 내용은 FastAPI와 Pydantic을 사용하는 백엔드 개발에서 자주 접하게 되는 상황입니다. 기본적으로 Pydantic의 검증 오류는 422 Unprocessable Entity 상태 코드와 함께 반환되는데, 이는 클라이언트가 구체적인 오류 원인을 구분하기 어렵게 만들 수 있습니다.
이 문제를 해결하기 위해 몇 가지 접근 방안을 고려해볼 수 있습니다:
커스텀 예외 처리: Pydantic의 검증 오류를 잡아서 원하는 형태의 응답을 생성할 수 있습니다. FastAPI의 @app.exception_handler
데코레이터를 사용하여 커스텀 예외 핸들러를 정의할 수 있습니다. 이를 통해 클라이언트가 이해할 수 있는 특정 코드와 메시지를 포함한 JSON 응답을 반환할 수 있습니다.
비즈니스 로직에서 처리: 클라이언트가 특정 오류 조건에 대해 상세하고 맞춤화된 피드백을 받길 원한다면, Pydantic 검증보다는 비즈니스 로직 내에서 입력값을 검증하고 커스텀 에러 메시지와 상태 코드를 반환하는 방법도 가능합니다.
에러 코드 사용: 백엔드가 오류의 종류를 식별하기 위해 커스텀 에러 코드를 정의할 수 있습니다. 예를 들어, 이메일 형식 오류를 특정 코드로, 길이 초과를 또 다른 코드로 나타내어 클라이언트가 쉽게 처리할 수 있도록 할 수 있습니다.
FastAPI를 활용한 유사한 사례로 FastAPI 커스텀 예외 처리와 유효성 검사에 대한 문서가 도움이 될 수 있습니다.
BH J님께서 말씀하신 전략은 클라이언트 측에서 에러를 명확히 구분하고 처리하는 데 있어 매우 현실적인 접근 방법 중 하나입니다. 최적의 솔루션은 프로젝트의 요구 사항과 팀의 정책에 따라 다를 수 있으니 여러 방법을 고려하여 가장 적합한 것으로 선택하시길 바랍니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.