HTTP 201 Created: 의미

이 오류의 의미와 확인 방법

• API 클라이언트, 브라우저 기반 애플리케이션, 모니터링 도구 또는 검사기가 201 Created를 보고합니다.
• 응답에 새로 생성된 객체, 리소스 메타데이터 또는 Location 헤더가 포함될 수 있습니다.
• 특정 경로, HTTP 메서드, 계정 또는 요청 페이로드에서만 결과가 나타날 수 있습니다.
• 성공적인 201 응답에도 응답 본문에 애플리케이션 수준의 경고나 유효성 검사 세부 정보가 포함될 수 있습니다.
• HTTP를 사용하는 엔드포인트가 응답을 반환했기 때문에 DNS 및 TLS 검사는 여전히 성공할 수 있습니다. 이러한 검사는 HTTP 상태 코드와 별개입니다.

가능성이 높은 순서의 주요 원인

1. 예상된 리소스 생성: 해당 경로가 레코드, 계정, 업로드, 작업, 주문 또는 기타 리소스를 의도적으로 생성하며 성공 후 201을 반환합니다.
2. 리소스를 생성하는 메서드 사용: 클라이언트가 리소스를 생성하도록 설계된 엔드포인트에 POST 또는 PUT 요청을 보냈습니다. 201이 적절한지는 메서드와 경로에 따라 결정됩니다.
3. 요청이 반복되었거나 잘못된 경로로 전송됨: 기존 리소스를 업데이트하거나 다른 URL을 사용해야 하는데 클라이언트, 연동 또는 폼이 생성 엔드포인트를 대상으로 요청했을 수 있습니다.
4. 애플리케이션 또는 라우팅 동작 변경: 배포, 컨트롤러, 핸들러 또는 경로 규칙이 요청에 반환되는 상태 코드를 변경했을 수 있습니다.
5. 중간 구성 요소가 응답을 생성하거나 수정함: 특히 직접 요청과 공개 요청의 헤더가 다를 때 reverse proxy, CDN, WAF 또는 gateway가 관여했을 수 있습니다.
6. 클라이언트의 해석이 오해를 일으킴: 모니터링 규칙이 오류가 아닌 모든 HTTP 응답을 비정상으로 분류할 수 있지만, 해당 엔드포인트에서 201은 유효할 수 있습니다.

해결 방법

먼저 HTTP 201이 예상된 응답인지 결정하세요

1. 정확한 URL, HTTP 메서드, 요청 본문 또는 관련 매개변수, 계정 컨텍스트 및 타임스탬프를 기록하세요. 공유 메모에는 비밀번호, 쿠키, 액세스 토큰 또는 기타 비밀을 포함하지 마세요.
2. 엔드포인트의 문서화된 동작 또는 애플리케이션 계약을 확인하세요. 생성 엔드포인트는 일반적으로 201을 반환하지만, 읽기 전용 페이지 요청이 리소스를 생성해서는 안 됩니다.
3. 응답 본문과 헤더를 확인하세요. Location 헤더, 리소스 식별자, 콘텐츠 유형, 요청 ID, 캐시 정보 및 애플리케이션 수준의 경고를 찾으세요. 헤더는 특정 구성 요소가 응답을 생성했다는 증명이 아니라 근거로 활용하세요.
4. 클라이언트가 리디렉션을 따랐는지 또는 중간 응답을 보고했는지 확인하세요. 최종 응답은 이전 응답과 구분하여 기록하세요.

API 사용자 또는 방문자인 경우

1. 작업이 무언가를 생성해야 했다면 요청을 다시 제출하기 전에 애플리케이션에서 새 리소스가 존재하는지 확인하세요.
2. 아무것도 생성하지 않아야 하는 작업이었다면 반복 재시도를 중단하고 경로, HTTP 메서드 및 클라이언트 설정을 확인하세요.
3. 인증이 필요한 경우 일반적인 애플리케이션 흐름으로 로그인한 뒤, 안전하고 권한이 있는 경우에만 다시 시도하세요.
4. 정제한 URL과 메서드, 타임스탬프, 관련 응답 헤더 및 가능한 경우 요청 ID를 사이트 운영자에게 제공하세요. 자격 증명, 세션 쿠키 또는 API 비밀은 절대 공유하지 마세요.

애플리케이션 또는 사이트를 운영하는 경우

1. 안전한 환경 또는 권한이 부여된 테스트 계정으로 요청을 재현하세요. 메서드, URL, 상태 코드, 응답 헤더 및 민감 정보가 삭제된 응답 본문을 캡처하세요.
2. 응답을 생성한 구성 요소를 식별하세요. 애플리케이션 핸들러, 웹 서버, reverse proxy, CDN, WAF 또는 기타 gateway일 수 있습니다. 가능한 경우 서버에서 생성한 요청 ID 또는 타이밍 헤더를 로그와 비교하세요.
3. 기록한 타임스탬프에 해당하는 애플리케이션 및 인프라 로그를 확인하세요. 리소스가 실제로 생성되었는지, 작업이 한 번만 커밋되었는지 아니면 여러 번 커밋되었는지 확인하세요.
4. 경로, 컨트롤러, 요청 처리, 인증, 프록시 규칙 및 배포에 대한 최근 변경 사항을 검토하세요. 멱등성이 없는 생성 요청을 재시도할 수 있는 클라이언트에 특히 주의하세요.
5. 해당 엔드포인트에서 201이 잘못된 경우 응답을 제어하는 가장 범위가 좁은 애플리케이션 또는 라우팅 규칙을 변경하세요. 운영 환경에 적용하기 전에 승인을 받고 변경 사항을 테스트하세요.
6. 동일한 메서드, URL 및 페이로드로 다시 테스트한 다음 관련 생성, 조회 및 업데이트 경로를 테스트하여 의도한 상태 코드와 리소스 동작이 유지되는지 확인하세요.

예방 및 해결 확인 방법

• 생성 및 중복 요청 동작을 포함하여 각 공개 경로에 대해 예상 HTTP 메서드와 상태 코드를 정의하세요.
• 배포 후 대표적인 인증 및 비인증 사례로 생성, 조회 및 업데이트 작업을 테스트하세요.
• 클라이언트가 201을 명시적으로 처리하고 재시도하기 전에 반환된 리소스 또는 Location 헤더를 확인하도록 하세요.
• 요청 식별자를 사용하고 예기치 않은 응답을 추적할 수 있을 만큼 충분한 기간 동안 애플리케이션, 프록시 및 gateway 로그를 보관하세요.
• 모든 2xx 응답을 동일하게 취급하지 말고 경로와 메서드별 상태 코드 비율을 모니터링하세요.
• 라우팅, 인증, 프록시 및 애플리케이션 변경 사항을 버전 관리하고 의도적인 201 응답을 문서화하세요.

자주 묻는 질문