HTTP Status Code

HTTP Status Code? 💯

HTTP Status Code : 클라이언트가 보낸 HTTP 요청에 대한 서버의 응답 코드로, 상태 코드에 따라 요청의 성공/실패 여부를 판단함.

2XX SUCCESS

200번대의 상태코드는 서버가 클라이언트에게 요청이 성공적으로 처리되었을때 보내는 코드들이다.

200번(OK) ▶ 클라이언트의 요청을 서버가 정상적으로 처리했다.

HTTP/1.1 200 OK
{
"result" : false
"status" : 400
}

위와 같이 성공했다는 200코드를 보냈지만 실제내용은 실패인 경우로 쓰이는 사례가 있다면 당장 수정하자.

---

201번(Created) ▶ 클라이언트의 요청을 서버가 정상적으로 처리했고 새로운 리소스가 생겼다.

201 상태 코드는 POST, PUT 요청에 대한 응답에 주로 사용된다.

---

202번(Accepted) ▶ 클라이언트의 요청은 정상적이나, 서버가 아직 요청을 완료하지 못했다.

클라이언트의 요청이 정상적이면 서버에선 작업의 성공/실패 응답하는 게 일반적이나, 작업 완료를 위한 일련의 작업들이 오래 걸리기 때문에 나중에 알려주겠다는 의미다.

---

204번(No Content) ▶ 클라이언트의 요청은 정상적이다. 하지만 컨텐츠를 제공하지 않는다.

자원 삭제 요청을 했고 이 요청이 유효하니 서버는 해당 자원을 삭제했다. 더 이상 응답할 컨텐츠가 없기 때문에 컨텐츠가 없는 204로 응답한다.

(여기서 주의할 점은 200으로 응답하고 응답 body에 null, {}, [], false 등으로 응답하는 것과 다르다는 것이다. 204의 경우 HTTP Response body가 아예 존재하지 않는 경우다.)

Example

PUT

• 자원 수정 요청의 결과가 기존의 자원 내용과 동일하여 변경된 내용이 없을 때 204로 응답할 수 있다.

• 만약 수정 요청으로 자원의 내용이 변경된다면 201로 응답할 것이다.

DELETE

• 삭제 요청으로 자원을 삭제하여 더 이상 존재하지 않고 그 자원을 참조하는 모든 자원도 삭제되어 더 이상 HTTP body를 응답하는 것이 무의미해졌을 때 사용한다.

4XX Client errors

4XX의 상태 코드들은 클라이언트의 요청이 유효하지 않아 서버가 해당 요청을 수행하지 않았다는 의미다.

400번(Bad Request) ▶ 클라이언트의 요청이 유효하지 않아 더 이상 작업을 진행하지 않는 경우

클라이언트로부터 요청이 들어오면 작업을 바로 진행하지않고 유효성검사부터 하는것이 옳다.

대부분의 API는 사전에 유효성 검증을 통해 400 상태 코드로 클라이언트에게 유효하지 않은 요청임을 응답한다.

그러나, 400 상태 코드로 응답하는 것만으로는 부족하다.

오류 발생 시 파라미터의 위치(path, query, body), 사용자 입력 값, 에러 이유를 꼭 명시하는 것이 좋다.

Example

class RequiredKeys {
  constructor(REQUIRED_KEYS) {
    this.REQUIRED_KEYS = REQUIRED_KEYS;
  }
  verify() {
    for (let key in this.REQUIRED_KEYS) {
      if (!this.REQUIRED_KEYS[key] && this.REQUIRED_KEYS[key] !== 0) {
        const err = new Error(`${key} 정보가 올바르지 않습니다.`);
        err.status = 400;
        throw err;
      }
    }
  }
}

---

401번(Unauthorized) ▶ 클라이언트가 권한이 없기 때문에 작업을 진행할 수 없는 경우

상태 코드 이름만 보면 권한(authorized)에 대한 내용처럼 보이지만, 사실 인증(authenticated)에 대한 이야기다.

401은 비인증이다.

---

403번(Forbidden) ▶ 클라이언트가 권한이 없기 때문에 작업을 진행할 수 없는 경우

403은 권한(authorized)에 대한 내용이다.

---

404번(Not Found) ▶ 클라이언트가 요청한 자원이 존재하지 않다.

404번에러는 크게 2가지로 나뉜다.

• 경로가 존재하지 않음

존재하지 않은 경로는 쉽게 404로 응답.(라우터에서 처리)

• 자원이 존재하지 않음

/users/:id 에서 id값이 만약 DB에 없는 값이라면 자원이 존재하지 않다는 의미이다.

따라서 존재하는 경로에 대한 요청이라도 자원이 존재하는지 파악 후, 존재하지 않는다면 404 상태 코드로 응답해야 한다

---

405번(Method Not Allowed) ▶ 클라이언트의 요청이 허용되지 않는 메소드인 경우

자원(URI)은 존재하지만 해당 자원이 지원하지 않는 메소드일 때 응답하는 상태 코드다.

완성도 높은 API를 제공하기 위해서는 사용하는것을 추천한다.

---

409번(Conflict) ▶ 클라이언트의 요청이 서버의 상태와 충돌이 발생한 경우

400, 401, 403, 404, 405 상태 코드에 속하기 애매한 오류의 상황들을 409로 응답한다.

Example

• 자원(URI) /users/1에 존재하는 메소드고 Not 405

• /users/:id에서 :id가 유효한 형식이고 Not 400

• 1 사용자도 존재하고 Not 404

• 헤더의 인증(X-TOKEN)도 정확하고 Not 401

• 삭제 권한도 있는 경우 Not 403

대부분의 예외처리를 해주었지만 로직자체가 문제있을 수 있다. 예를들면

사용자의 게시물이 존재하는 경우 사용자를 삭제할 수 없다는 비지니스 로직이 있을 수 있다.

이렇게 API 사용에 있어 비지니스 로직상 모순이 발생하여 처리가 불가능한 경우 응답하는 상태 코드다.

  const isExistItem = new IsExistItem(check, resultType, 409);
  isExistItem.existErr('이미 품목에 있습니다.');

오류 상황과 마찬가지로 응답 시 오류의 원인을 알려야 한다.

---

429번(Too Many Requests) ▶ 클라이언트가 일정 시간 동안 너무 많은 요청을 보낸 경우

해커는 사용자의 비밀번호를 알아내기 위해 POST /login API에 password를 무차별로 대입하면서 요청할 수 있다.

서버 입장에선 자원의 기밀성(Confidentiality)에 피해를 입을 수 있는 공격이면서, 이러한 무차별 요청으로 다른 요청을 처리할 수 없거나 처리가 늦을 수 있는 가용성(Availability)에 피해를 입을 수 있다.

서버는 이러한 공격에 대비해 인증 API의 경우 각 클라이언트는 n 시간 동안 n 회만 요청 가능하다는 룰을 정하고 이것을 초과하면 429 상태 코드를 응답해야 한다.

5XX SERVER ERRORS

5XX 상태 코드들은 서버 오류로 인해 요청을 수행할 수 없다는 의미다.

• API를 사용하는 클라이언트에게 5XX 상태 코드는 나타내지 말아야 한다.

• 최신의 웹 애플리케이션 프레임워크는 자체 웹서버를 내장하고 있어서 웹서버(Apache, Nginx) 없이 운영할 수 있다.

• 그러나, 보통 운영 레벨에서 이렇게 하는 경우는 드물고 앞에 웹서버를 두고 웹 애플리케이션을 연결해서 운영한다.

• 따라서, 상단의 웹서버(Apache, Nginx)에서 발생하는 어쩔 수 없는 오류를 제외하고 API에선 5XX 상태 코드가 응답되선 안된다.

• API 레벨에선 완벽한 예외처리를 통해 5XX 서버 오류 상태 코드를 방지해야 한다.