내가 한 노력들

HTTP 상태코드 총정리 ( + Redirect / PRG의 개념) 본문

IT 공부/Network

HTTP 상태코드 총정리 ( + Redirect / PRG의 개념)

JONGI-N CHOI 2021. 10. 20. 12:34

상태코드

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

100번대 (Informational)

- 요청이 수신되어 처리중

- 거의 사용하지 않음!! 

200번대 (Successful)

- 요청 정상 처리

주요 코드

200 Ok

HTTP/1.1 200 OK
Content-Type: appllication/json
Content-Length: oo 

{
	"name": "jongin",
	"age": 28,
}

리소스를 요청했을 때, 성공적으로 응답이 됐을 경우 받을 수 있는 상태 코드 

201 Created

HTTP/1.1 201 Created
Content-Type: appllication/json
Content-Length: oo 
Location: /members/100

{
	"name": "jongin",
	"age": 28,
}

신규 리소스를 만드는 요청을 보내, 성공했을 경우 받을 수 있는 상태 코드 

+

POST 메서드로 요청했을 경우에는, 서버에서 Location을 만들어서 응답한다.

202 Accepted

- 요청이 접수되었으나 처리가 완료되지 않았음

- 배치 처리 같은 곳에서 사용 

204 No Content

서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음

 

- 웹 문서 편집기에서 save 버튼 

- save 버튼의 결과로 아무 내용이 없어도 된다.

- save 버튼을 눌러도 같은 화면을 유지해야 한다.

- 결과 내용이 없어도 204 메시지만으로 성공을 인식할 수 있다. 

300번대(Redirection)

요청을 완료하려면, 클라이언트(웹브라우저)의 추가 행동이 필요

 

웹브라우저는 300번대의 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

 

리다이렉션의 이해

영구 리다이렉션

- 특정 리소스의 URI가 영구적으로 이동

- 301, 308 상태코드 (기본적으로 같은 기능) 

301 (Moved Permantly)

리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음

 

흐름

1. 요청

GET /event HTTP/1.1
Host: localhost:8080

서버에서는 현재, /event라는 URI대신 /new-event를 사용하고 있어서 /event가 존재하지 않음 

 

2. 응답

HTTP/1.1 301 Moved Permanently
Location: /new-event

301 상태코드를 응답하고, Location에 /new-event를 넣어서 줍니다. 

 

그럼 브라우저는 301의 상태코드를 바고 Location도 받았기 때문에 스스로 /new-event로 redirect를 하게 됩니다.

그러면, 다시 새로운 URI로 요청

 

3. 요청

GET /new-event HTTP/1.1
Host: localhost:8080

4. 응답

HTTP/1.1 200 OL
~~

 

308 (Permanet Redirect)

- 301과 기능은 같고, 메서드와 본문이 유지됨

 

- 원래의 URL을 사용 x, 검색 엔진 등에서도 변경 인지 

- /members -> /users

- /event -> /new-event

 

301과 308의 차이!

301

리소스 URL이 변경되어, 새로운 Location을 받아 Redirect 할 때, 처음에 POST로 요청을 했어도 Location된 곳으로 다시 요청을 보낼 경우에는 GET으로 바뀌고, 본문의 내용도 사라집니다. 

 

308

POST가 유지되고, 본문의 내용도 유지 됩니다. 

 

이게 무슨차이냐??

301은 Form에 입력을해서 요청을 보내면, POST 메서드와 body에 내용을 담아서 보내게 되는데 , 301 상태코드와 Location을 받으면, 다시 요청 보낼 때에는 GET메서드로 변경이되고 body에 내용이 사라지게 되어, 처음부터 다시 Form에 정보를 입력해야만 하는 상황이 됩니다. 

 

308은 POST메서드와 본문이 유지되기 때문에, 그대로 요청을 받아 서버에서는 처리하고 완료됐다는 200번대 상태코드를 받을 수 있습니다. 

 

하지만!

308이 훨씬 편리해보이지만, 301을 더 많이 쓰고있습니다. 

그 이유는, URL리소스가 변경되었다는 것은 Form 양식 같은 것이 변경되었을 가능성이 크기 때문에 새롭게 다시 입력을 받아야만 하기 때문에 301을 많이 사용합니다. 

 

일시 리다이렉션 

- 일시적인 변경

- 302, 307, 303 상태코드

302 (Found) 

- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 

307 (Temporary Redirect)

- 302와 기능은 같음, 리다이렉트시 메서드와 본문 유지

303 (See Other)

- 302와 기능은 같음, 리다이렉트시 요청 메서드가 GET으로 변경 

 

302와 303의 차이는 302는 GET으로 변경이 안될 수도 있음 303은 무조건 GET으로 변경이됨

 

- 주문 완료 후 주문 내역 화면으로 이동

 

PRG: Post/Redirect/Get

POST로 주문후에 웹 브라우저는 새로고침했을 때.

새로고침은 다시 요청을 하기 때문에, POST로 다시 한번 요청이 들어간다. = 중복 주문 요청이 된다. 

 

1. 요청

POST /order HTTP/1.1
Host: www.naver.com

itemId=3&itemName=computer&count=1

2. 서버에서 주문데이터 저장 

 

3. 응답

HTTP/1.1 200 OK

<html>
  주문완료내용
</html>

4. 새로고침 

5. 요청

POST /order HTTP/1.1
Host: www.naver.com

itemId=3&itemName=computer&count=1

redirect를 하면, 마지막 요청이 다시한번 실행되기 때문에 중복 주문 요청이 들어감 

 

6. 서버에서 주문 데이터 저장

 

7. 응답

HTTP/1.1 200 OK

<html>
  주문완료내용
</html>

 

위와같은 상황을 막기 위해서는???????????

302 or 303 상태코드를 이용하자

 

1. 요청

POST /order HTTP/1.1
Host: www.naver.com

itemId=3&itemName=computer&count=1

2. 서버에서 주문데이터 저장 

 

3. 응답

HTTP/1.1 302 Found
Location: /orderResult/3

4.  300번대 상태코드에 Location정보가 같이 들어왔네? -> 브라우저에서 자동적으로 Redirect

 

5. 요청

GET /orderResult/3 HTTP/1.1
Host: www.naver.com

302상태코드를 받아 Redirect가 되면, GET메서드로 변경되고, 본문의 내용은 사라짐 

 

6. 결과페이지 조회 

 

7. 응답

HTTP/1.1 200 OK

<html>
  주문완료 결과페이지
</html>

 

302 상태코드로 처리하게 되면, 새로고침을 계속해도 결과페이지만 GET으로 요청을 보내기 때문에 중복 결제 문제가 발생되지 않음 

 

 

 

특수 리다이렉션

300 Multiple Choices

안씀..

 

304 Not Modified

- 캐시를 목적으로 사용 

 

- 클라이언트에게 리소스가 수정되지 않았음을 알려준다. -> 클라이언트는 로컬 PC에 저장된 캐시를 재사용(캐시로 리다이렉트 한다.)

 

- 304 응답은 응답에 메시지 바디를 포함하면 안됨 ( 로컬 캐시를 사용하니까 )

 

 

400번대 (Client Error)

클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음

클라이언트가 이미 잘못된 요청을 보내고 있기 때문에, 계속 재요청을해도 Error

 

요청구문, 메시지 등등 오류

클라이언트는 요청 내용을 검토하고 다시 보내야함

파라미터가 잘못되거나, API 스펙이 맞지 않을때

 

401 Unauthorized 

클라이언트가 해당 리소스에 대한 인증이 필요함

 

- 인증 Authentication : 본인이 누구인지 확인 ( 로그인 )

- 인가 Authorization : 권한부여( ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한)

 

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

 

- 주로 인증 자격은 있지만, 접근 권한이 불충분한 경우 

 

404 Not Found

- 요청 리소스가 서버에 없음  ( 서버에 리소스가 없는데 클라이언트쪽에서 요청했을 경우)

 

- 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때 

( 403오류를 내도 되지만, 아예 이런 페이지가 없다고 전달하고 싶은 경우에 ) 

 

 

 

500번대 (Server Error)

- 서버 오류, 서버가 정상 요청을 처리하지 못함 

- 서버 문제이기 때문에 재시도하면 성공할 수도 있다. ( 서버가 복구 되었을 때 )

 

500 Internal Server Error

- 서버 내부 문제로 오류발생

- 부분의 서버 문제는 500으로

 

503 Service Unavailable

서비스 이용 불가 

 

- 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 있음

- Retry-After 헤더 필드로 얼마뒤에 복구하는지 보낼 수 있음