응답 본문에 오류가있는 http 200 OK 반환

응답 본문에 오류가있는 http 200 OK 반환

---

HTTP 200 OK응답 본문 내부에 오류가 발생하여 서버 측 오류가 발생했을 때 반환하는 것이 올바른지 궁금합니다 .

예:

1. 우리는 http GET
2. 서버 측에서 예상치 못한 일이 발생했습니다.
3. 서버는 http 200 OK응답 내에 오류가있는 상태 코드를 반환 합니다 (예 :{"status":"some error occured"}

올바른 행동입니까? 상태 코드를 변경하면 안되나요?

---

아니요, 이것은 매우 정확하지 않습니다.

HTTP는 애플리케이션 프로토콜입니다. 200은 응답에 요청 된 리소스의 상태를 나타내는 페이로드가 포함되어 있음을 의미합니다. 오류 메시지는 일반적으로 해당 리소스의 표현이 아닙니다.

GET을 처리하는 동안 문제가 발생하면 올바른 상태 코드는 4xx ( "당신이 엉망이되었습니다") 또는 5xx ( "나는 엉망이되었습니다")입니다.

---

HTTP 상태 코드는 HTTP 프로토콜에 대해 설명합니다. HTTP 200HTTP 수준에서 전송이 정상임을 의미합니다 (즉, 요청이 기술적으로 정상이고 서버가 적절하게 응답 할 수 있음). 모든 코드와 그 의미의 목록은 이 위키 페이지 를 참조하십시오 .

HTTP 200은 "비즈니스 코드"의 성공 또는 실패와 관련이 없습니다. 귀하의 예에서는 HTTP 200기술적 인 문제로 인해 비즈니스 로직이 제대로 실행되지 않는 경우 "비즈니스 코드 오류 메시지"가 성공적으로 전송되었음을 나타내는 허용 가능한 상태입니다.

또는 서버에서 HTTP 5xx기술 또는 복구 불가능한 문제가 발생한 경우 서버가 응답하도록 할 수 있습니다 . 또는 HTTP 4xx들어오는 요청이 다시 문제 (예 : 잘못된 매개 변수, 예기치 않은 HTTP 방법을 ...)이 있다면,이 모두 표시 기술적 인 반면, 오류를 HTTP 200나타냅니다 NO 기술적 오류를하지만, 비즈니스 로직 오류에 대한 보장을하지 않습니다.

요약하면 : 예 : HTTP 상태 200과 함께 http 응답에 오류 메시지 (비 기술적 문제의 경우)를 보내는 것은 유효합니다. 이것이 귀하의 사례에 적용되는지 여부는 귀하에게 달려 있습니다. 예를 들어 클라이언트가 거기에없는 파일을 요청한다면 404. 서버에 잘못된 구성이있는 경우 500. 고객이 만석이 된 비행기의 좌석을 요청하는 경우 200귀하의 "구현"에 따라이를 인식 / 처리하는 방법이 결정됩니다 (예 : JSON 블록에 { "booking","failed" })

---

비즈니스 로직 오류를 HTTP 코드로 반환하고 싶은 경우에도 실제 오류를 잘못 표시하기 때문에 HTTP 200을 사용하는 대신 해당 오류에 대해 허용되는 HTTP 오류 코드가 없습니다.

따라서 HTTP 200은 비즈니스 논리 오류에 적합합니다. 그러나 HTTP 오류 코드가 다루는 모든 오류는이를 사용해야합니다.

기본적으로 HTTP 200은 사용자 요청을 올바르게 처리하는 서버를 의미합니다 (비행기에 좌석이없는 경우 사용자 요청이 올바르게 처리 되었기 때문에 문제가되지 않습니다. 비행기에서 사용 가능한 좌석 수만 반환 할 수도 있습니다. 비즈니스 로직 오류가 전혀 없거나 해당 비즈니스 로직이 클라이언트 측에있을 수 있습니다. 비즈니스 로직 오류는 추상적 인 의미이지만 HTTP 오류가 더 명확합니다.

---

명확히하기 위해 프로토콜에 맞는 HTTP 오류 코드를 사용해야하며 비즈니스 논리 오류 를 보내는 데 HTTP 상태 코드를 사용하지 않아야 합니다.

같은 오류 부족 균형 , 어떤 택시 사용할 수 , 잘못된 사용자 / 암호는 HTTP 자격 상태 200응용 프로그램의 특정 오류가 응답 본체의 처리와.

이 소프트웨어 엔지니어링 답변을 참조하십시오 .

프로토콜 분리에 대해 명시 적으로 설명하는 것이 좋습니다. HTTP 서버와 웹 브라우저가 자신의 일을하자, 앱이하자 그 자신의 일을. 앱은 요청을 할 수 있어야하고 응답이 필요합니다. 그리고 요청 방법, 응답 해석 방법에 대한 논리는 HTTP 관점보다 복잡 할 수 있습니다.

---

HTTP는 인터넷을 통한 데이터 전송을 처리하는 프로토콜입니다.

어떤 이유로 든 전송이 중단되면 HTTP 오류 코드가 전송 될 수없는 이유를 알려줍니다.

전송되는 데이터는 HTTP 오류 코드로 처리되지 않습니다. 전송 방법 만.

HTTP는 'Ok, this answer is gobbledigook, but here is'라고 말할 수 없습니다. 그것은 단지 말한다 200 OK.

즉 : 나는 당신에게 그것을 얻는 나의 일을 완료했고, 나머지는 당신에게 달려 있습니다.

이미 답변을 받았지만 이해할 수있는 단어로 작성했습니다. 반복해서 죄송합니다.

---

사람들이 프로토콜 문제에 비해 애플리케이션 로직에 너무 많은 비중을 두었다고 생각합니다. 중요한 것은 응답이 의미가 있어야한다는 것입니다. 동적 리소스를 제공하는 API가 있고 데이터 Z가있는 템플릿 Y에서 파생 된 X에 대한 요청이 있고 Y 또는 Z가 현재 사용할 수없는 경우 어떻게 되나요? 비즈니스 로직 오류입니까, 기술적 오류입니까? 정답은 "누가 신경써?"입니다.

API와 응답은 이해하기 쉽고 일관성이 있어야합니다. 어떤 종류의 사양을 준수해야하며 해당 사양은 유효한 응답이 무엇인지 정의해야합니다. 유효한 응답을 따르는 것은 200 코드를 생성해야합니다. 유효한 응답을 따르지 않는 항목은 유효한 응답을 생성 할 수없는 이유를 나타내는 4xx 또는 5xx 코드를 생성해야합니다.

사양의 유효한 응답 정의가 허용 { "error": "invalid ID" }하는 경우 성공적인 응답입니다. 사양이 해당 조정을 수행하지 않으면 200 코드로 해당 응답을 반환하는 것은 잘못된 결정입니다.

나는 함수를 호출하는 것에 비유를 그릴 것이다 parseFoo. 전화하면 parseFoo("invalid data")어떻게 되나요? 오류 결과를 반환합니까 (null 일 수 있음)? 아니면 예외가 발생합니까? 많은 사람들이 하나의 접근 방식이 올바른지 여부에 대해 거의 종교적인 입장을 취하지 만 궁극적으로 API 사양에 달려 있습니다.

"상태 코드 요소는 요청을 이해하고 충족하려는 시도의 결과를 제공하는 3 자리 정수 코드입니다."

"성공적으로 오류를 반환"하는 것이 HTTP 성공인지 오류인지에 대해서는 의견 차이가 있습니다. 나는 다른 사람들이 동일한 사양을 다른 방식으로 해석하는 것을 봅니다. 그러니 한 편을 선택하세요.하지만 어느 쪽이든 전 세계가 당신과 동의하지 않을 것이라는 점을 받아들이세요. 나를? 나는 중간 어딘가에 있지만 상식적인 고려 사항을 제공 할 것입니다.

1. 요청을 전달할 때 서버 측 코드가 예기치 않은 예외를 포착하면 500 Internal Server Error. 이것은 OP의 상황 인 것 같습니다. 응용 프로그램은 200예기치 않은 오류에 대해 a 를 반환해서는 안되지만 3 번 항목도 참조하십시오.
2. If your server-side code should be able to gracefully handle a given invalid input, and it doesn't constitute an "exceptional" error condition, your spec should accommodate HTTP 200 responses that provide meaningful diagnostic information.
3. Above all: Have a spec. Make it consistent. Stick to it.

In OP's situation, it sounds like you have a de-facto standard that unhandled exceptions yield a 200 with a distinguishable response body. It's not ideal, but if it's not breaking things and actively causing problems, you probably have bigger, more important problems to solve.

ReferenceURL : https://stackoverflow.com/questions/27921537/returning-http-200-ok-with-error-within-response-body