HTTP 상태코드 & HTTP 메서드

손효재·2021년 12월 25일
0

Network

목록 보기
1/6

HTTP 상태코드

클라이언트가 보낸 요청의 처리 상태를 응답해서 알려주는 기능

2xx (Successful) : 요청 정상 처리

200 OK : 요청 성공
201 Created : 요청을 성공해서 새로운 리소스가 생성됨
202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음, 배치 처리 같은 곳에서 사용
204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음. 결과 내용이 없어도 204 메시지만으로 성공을 인식할 수 있다.

200 vs 201

→ 200은 요청이 성공적으로 처리되었을 경우이고, 201은 200과 동일하게 요청을 성공했다는 의미이지만, 새로운 리소스가 생성되었다는 의미가 추가된 것이다. POST나 PUT 요청으로 성공과 동시에 게시물 작성이나 회원가입등의 새로운 데이터를 서버에서 생성하는 작업이 성공했을 때 반환한다.

3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요, 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동

영구 리다이렉션 (301, 308)

특정 리소스의 URI가 영구적으로 이동하고, 원래의 URL을 사용하지 않는다. 검색 엔진 등에서도 변경 인지

301 Moved Permanently : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (MAY)
308 Permanent Redirect : 301과 기능이 같다.
리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

일시 리다이렉션 (302, 307, 303)

리소스의 URI가 일시적으로 변경한다. 따라서 검색 엔진 등에서 URL을 변경하면 안됨

302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (MAY)
307 Temporary Redirect : 302와 기능은 같음, 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다. MUST NOT)
303 See Other : 302와 기능은 같음, 리다이렉트시 요청 메서드가 GET으로 변경

PRG : Post/Redirect/Get

POST로 주문후에 새로고침으로 인한 중복 주문 방지

  • POST로 주문 후에 주문결과 화면을 GET 메서드로 리다이렉트한다.
  • 새로고침해도 결과 화면을 GET으로 조회하게 된다.

정리

처음 302 스펙의 의도는 HTTP 메서드를 유지하는 것인데, 웹 브라우저들이 대부분 GET으로 바꿔버렸다.
그래서 모호한 302 대신 명확한 307,303이 등장하게 되었다.

  • 307,303을 권장하지만 현실적으로 이미 많은 어플리케이션 라이브러리가 302를 기본값으로 사용
  • 자동 리다이렉션시에 GET으로 변해도되면 그냥 302를 사용해도 큰 문제 없음

특수 리다이렉션 (304)

304 Not Modified : 캐시를 목적으로 사용한다.
클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다 (캐시로 리다이렉트 한다) 304 응답은 응답에 메시지 바디를 포함하면 안된다 (로컬 캐시를 사용해야 하므로)

4xx (Client Error) : 클라이언트 오류

오류의 원인이 클라이언트에 있는 것으로 잘못된 문법등으로 서버가 요청을 수행할 수 없다.
클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기때문에, 똑같은 재시도가 실패한다.

400 Bad Request : 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
서버에서 철저하게 validation해서 API 스펙이 맞지않다면, 400에러를 반환시켜야한다
401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증(Authentication)이 필요함
403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함 (인증 자격은 있지만, 접근 권한이 불충분한 경우)
404 Not Found : 요청 리소스를 찾을 수 없음

401 vs 403

→ 둘은 인증(Authentication, 401)과 인가(Authorization, 403)의 차이이다.
401은 클라이언트가 인증되지 않았거나, 유효한 인증정보가 부족하여 요청이 거부된 것으로, 사용자가 로그인되지 않은 경우가 예시이다.
403은 서버가 해당 요청을 이해했지만, 권한이 없어 요청이 거부된 것으로, 사용자가 권한이 없는 요청을 하는 경우가 예시이다.

인증(Authentication) : 본인이 누구인지 확인 (로그인)
인가(Authorization) : 권한 부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한,
인증이 있어야 인가가 있음)

5xx (Server Error) : 서버 오류

서버 문제로 정상 요청을 처리하지 못함
서버에 문제가 있기 때문에 재시도 하면 성공할 수 있다.

500 Internal Server Error : 서버 내부 문제로 오류 발생, 애매하면 500 오류
503 Service Unavailable

  • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
  • Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음

HTTP 메서드

  • GET : 리소스 조회
  • POST : 요청에 포함된 표현을 처리 (새 리소스 생성(등록), 요청 데이터(프로세스) 처리)
  • PUT : 리소스를 대체, 해당 리소스가 없으면 생성
  • PATCH : 리소스를 부분 변경
  • DELETE : 리소스 삭제
  • HEAD : GET과 동일하지만, 메시지부분을 제외하고, 상태 줄과 헤더만 반환
  • OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)
  • CONNECT : 대상 자원으로 식별되는 서버에 대한 터널 설정
  • TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 설정

GET, POST의 차이는?

GET은 리소스를 조회하는 메서드이고, POST는 요청에 포함된 표현을 처리하는 메서드이다.

데이터를 전달할 때, GET은 주로 쿼리 파라미터나 쿼리 스트링을 사용하고,
POST는 메시지 바디를 통해 데이터를 전달한다.

GET은 POST와 다르게, 호출해도 리소스가 변경되지 않기 때문에 ‘안전’한 메서드 이며,
여러번 호출해도 결과가 모두 같기 때문에 ‘멱등’하다고 할 수 있다.

GET은 캐싱해서 사용할 수 있다. 사실 스펙상 GET,HEAD,POST,PATCH 모두 캐시가 가능하지만,
POST나 PATCH는 메시지 바디 내용까지 캐시 키로 구현해야해서 어렵다.

* 안전한 메서드(Safet Method)
GET, HAED와 같이 호출해도 서버측의 상태 정보를 변경하지 않는 메서드를 말한다.
이렇게 안전한 메서드는 서버의 상태를 아예 변경시키지 않는다.

그렇다면 GET은 항상 캐싱이 될까?

PUT, PATCH의 차이는?

  1. update 방식의 차이, 요청한 URI에 자원이 존재하지 않을 때

PUT은 전체 리소스를 대체한다.(덮어버린다) 리소스가 있으면 대체하고, 없다면 새로 생성한다.
PATCH는 리소스를 부분 변경한다. 리소스가 없어도 새로운 자원을 생성하지 않는다.

  1. 멱등성의 관점 (PUT은 멱등성이 보장되지만, PATCH는 멱등성이 보장될 수도, 되지 않을 수도 있다.)

PUT은 서버에 존재하는 리소스를 요청에 담긴 내용대로 통째로 대체해버리므로, 여러번 수행되어도 결과 값은 변하지 않을 것이기 때문에 멱등성을 가진다.

PATCH는 구현 방법에 따라서 PUT 메서드처럼 멱등성이 보장될 수도 있고, 보장되지 않을 수도 있다.
→ PATCH 메서드는 PUT 메소드처럼 리소스를 대체하는 행위가 아니기 때문에 요청을 어떤 방식으로 사용하는지에 대한 제한이 딱히 없기 때문이다.
PATCH의 구현을 PUT과 동일한 방식으로 수정할 리소스의 일부분만 담아서 보내는 경우 멱등성을 가진다.
PUT과 같이 요청 Body에 덮어쓸 데이터만 위치하도록 구현을 할 경우, 같은 요청을 여러번 하더라도 같은 결과가 나온다. 즉, 멱등성을 가진다고 할 수 있는 것이다.
하지만, 나이를 증가시키는 API에서 메시지 바디에 증가하고싶은 속성과 증가시킬 value를 전달한다면,
호출시마다 나이가 1씩 증가하기 때문에 멱등성을 보장하지 않는다.

HTTP Method "멱등성"

1번,2번,100번 호출로 인한 서버 상태 결과가 모두 같은 것을 의미한다. ex) GET, PUT, DELETE
POST,PATCH는 2번 호출하면 같은 결제가 중복해서 발생하므로 멱등이 아니다.

멱등한 메서드는 서버의 상태를 변경 시킬 수 도 있고, 시키지 않을 수도 있다.
하지만, 요청한 사항이 에러가 나거나, 지연이 발생하지 않는 한 요청에 대한 서버의 상태는 항상 같다.

멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.
멱등하다면, 서버가 TIMEOUT등의 이유로 정상 응답을 못주었을때,
클라이언트가 같은 요청을 다시 해도되는가를 판단할 수 있는 근거가 될 수 있다.

0개의 댓글