2016-11-17 4 views
0

사용자의 비밀번호를 업데이트하는 애플리케이션에 대한 패치 요청이 있습니다. 우리는 1 비즈니스 규칙을 제외하고 모든 잘못된 입력을 차단하는 엠버 유효성 검사기를 가지고 있습니다. 이는 지난 5 개의 암호 중 하나로서 사용 된 암호가 아니어야합니다.REST-API 패치 요청의 잘못된 입력에 대한 HTTP 상태 코드

우리는 현재이 경우 400 개의 잘못된 요청을 반환하고 있지만 대부분의 응용 프로그램이 SOAP이고 단지 200 및 300을 예상하기 때문에 회사는 구성 요소 가용성을위한 대시 보드를 가지고 있으며 400 및 500 개의 요청을 사용할 수 없다고 계산합니다. UI를 통해이 400을 적절하게 처리 할지라도 여전히 우리에게 불리한 점입니다. 그리고 가용성이 떨어지는 지역으로 우리를 레이더에 올려 놓습니다.

우리는 가용성을 모니터링하고 REST 서비스에 대해이 설정을 변경해야합니다. 회사가 더 많은 REST 응용 프로그램을 작성함에 따라 이것이보다 일반적인 공통적 인 사건이되기 때문입니다. 아니면 암호가 성공적으로 업데이트되지 않았다는 내용의 동굴 200 개를 반환합니까?

+2

나는 정말로 모니터링이 고장 났다고 생각한다. 적어도 400 개의 오류는 잘못된 가용성의 징조가 아닙니다. – Lux

+0

REST는 프로토콜이 아닌 아키텍처 스타일 일 뿐이지 만 시나리오에서 사용되는 기본 프로토콜 인 HTTP를 준수합니다. 따라서 사용중인 프로토콜의 기능을 존중하고 재사용해야합니다. 즉 잘못된 입력에 대해 오류 코드를 반환해야합니다. 입력 데이터가 유효하지 않은 요청에 대해 200 OK를 반환하면 RESTful 클라이언트가 잘못된 데이터에서 작동하므로 더 많은 잘못된 입력이 발생할 수 있습니다. –

답변

0

나는 400 응답이 서비스에 부적합하다고 주장한다. 마지막 5 개의 암호 내에서 사용자의 암호가 반복 될 때 서비스가 400으로 응답하면 이라는 요청이 서버에 의해으로 인식됩니다. W3C 따르면

:

요청이 잘못되어 구 서버가 요구를 이해할 수 없다. 클라이언트는 수정없이 요청을 반복해서는 안됩니다 (SHOULD NOT).

귀하의 경우 요청이 이해되었습니다. 응용 프로그램 (암호 재사용과 관련하여)을 알리기 위해 400을 반환합니다. 200 응답은 응용 프로그램 문제를 나타내는 페이로드가 더 적절할 것이라고 생각합니다.

편집 : 하나 또한 422 response 순서대로 될 것이라고 주장 할 수 있습니다 따라서 (

422 (처리 할 수 ​​없음 법인) 상태 코드는 서버 요청 엔티티의 내용 유형을 이해하고 의미 415 (지원되지 않는 미디어 유형) 상태 코드가 부적절합니다.) 요청 엔터티의 구문이 올바른지 (따라서 400 (잘못된 요청) 상태 코드가 부적절 함) 포함 된 명령을 처리하지 못했습니다. 예를 들어, XML 요청 본문에 형식이 올바른 (즉, 구문 상 올바르다) 의미 상 오류가있는 XML 지침 인 이 포함되어 있으면이 오류 상태가 발생할 수 있습니다.