http

markyang92·2022년 1월 15일
http
0

network

목록 보기
16/21
post-thumbnail

URI, URL

  • URI는 Locator, Name 또는 둘다 추가로 분류될 수 있다.
    • URI: Uniform(리소스를 식별하는 통일된 방식) Resource(자원) Identifier(식별자)
      • URL: Locator (위치)
      • URN: Name


HTTP 상태코드

  • client가 server로의 요청 처리 상태를 응답해서 알려줌
    • 클라이언트가 모르는 상태코드가 나타나면, 클라이언트는 상위 상태코드로 해석 처리
    • 399?.. 399는 모르겠고, 3--이니 뭔가 추가행동이 필요하겠군!
상태 코드설명
1xx(informal)요청이 수신되어 처리중
2xx(Successful)요청 정상 처리
3xx(Redirection)요청을 완료하려면, 추가 행동이 필요
4xx(Client Error)클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
5xx(Server Error)서버 오류, 서버가 정상 요청을 처리하지 못함

2xx : 성공

클라이언트의 요청을 성공적 처리

상태 코드설명추가 설명
200OK처리 완료
201Created클라이언트가 요청한 것을 서버에서 무언가를 생성했다.
202Accepted요청이 접수되었으나 처리가 완료되지 않았음
204No Content서버가 요청을 성공적으로 수행했으나, 응답 페이로드 본문에 보낼 데이터가 없음
  • 웹 문서 편집기에서 save버튼 클릭
  • save 버튼의 결과로 아무 내용이 없어도 된다.
  • save 버튼을 눌러도 같은 화면을 유지해야 한다.
  • 결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.

    • 200 OK

    • 요청 성공
    • 클라이언트: 요청
    GET /members/100 HTTP/1.1
Host: localhost:8080
    • 서버: 응답
    HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34

{
    "username": "yang",
    "age": 20
}

    201 Created

    • 요청 성공해서 새로운 리소스가 생성됨
    • 클라이언트: 요청
    POST /members HTTP/1.1
Content-Type: application/json

{
    "username": "yang",
    "age": 20
}
    • 서버: 응답
    HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100 # 생성된 리소스는 응답의 Location 헤더 필드로 식별

{
    "username": "yang",
    "age": 20
}
    • 201을 받았으면, 클라이언트는 서버에서 무엇을 생성했구나!, Location 헤더가 있겠구나!

    202 Accepted

    • 요청이 접수되었으나 처리가 완료되지 않았음
    • 클라이언트: 요청
    POST /members HTTP/1.1
Content-Type: application/json

{
    "username": "yang",
    "age": 20
}
    • 서버: 응답
    HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100 # 생성된 리소스는 응답의 Location 헤더 필드로 식별

{
    "username": "yang",
    "age": 20
}

    3xx : Redirection

    • 웹브라우저는 3xx 응답에, Location 헤더가 오면, 자동적으로 Redirect한다.
    상태 코드설명추가 설명
    300Multiple Choices잘 사용되지 않음
    301Moved Permanently영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동
  • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
    • 302Found일시적인 리다이렉션: 리소스의 URI가 일시적으로 변경
  • 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수 있음
  • 자세한 설명은 일시적인 리다이렉션 참고
  • 302 스펙의 의도는 HTTP 메서드를 유지하는 것
  • 그런데 웹 브라우저들이 대부분 GET으로 바꾸어버림
  • 그래서 모호한 302를 대신하는 명확한 307, 303등이 등장함
  • 메서드가 GET으로 변할 수 있음
    • 303See Other일시적인 리다이렉션: 302와 기능은 같음
  • 리다이렉트시 요청메서드가 GET으로 변경
    • 메서드가 GET으로 변경
    304Not Modified캐시를 목적으로 사용
  • 클라이언트에게 리소스가 수정되지 않았음을 알려준다.
    따라서, 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다.
    즉, 클라이언트는 캐시로 리다이렉트
  • 304 응답은 응답에 메시지 바디를 포함하면 안된다.(로컬 캐시를 사용해야 하므로)
  • 조건부 GET, HEAD요청 시 사용
    • 307Temporary Redirect일시 리다이렉션: 302와 기능은 같음
  • 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안된다
    • 308Permanent Redirect영구 리다이렉션: 특정 리소스의 URI가 영구적으로 이동
  • 301과 기능은 같음
  • 리다이렉트시 요청 메서드와 본문 유지

    • 301: Moved Permanently

    1. 클라이언트: 요청
    POST /event HTTP/1.1
Host: localhost:8080
  
name=hello&age=20    # <- 메시지 존재
    1. 서버: 응답
    HTTP/1.1 301 Moved Permanently
Location: /new-event
    1. 클라이언트: 요청, 자동 리다이렉트
    GET /new-event HTTP/1.1 # <- GET으로 변경되고, URL이 /new-event로 리다이렉트
Host: localhost:8080
                        # <- 원래 메시지가 사라짐. 즉, /new-event 화면만 보여질 것임
    1. 서버: 응답
    HTTP/1.1 200 OK
...

    308: Permanent Redirect

    1. 클라이언트: 요청
    POST /event HTTP/1.1
Host: localhost:8080
  
name=hello&age=20    # <- 메시지 존재
    1. 서버: 응답
    HTTP/1.1 308 Permanent Redirect
Location: /new-event
    1. 클라이언트: 요청, 자동 리다이렉트
    POST /new-event HTTP/1.1 # <- POST로 유지. URL이 /new-event로 리다이렉트
Host: localhost:8080

name=hello&age=20        # <- 원래 메시지 유지
    1. 서버: 응답
    HTTP/1.1 200 OK
...

    일시적 리다이렉션의 예

    • PRG: Post/Redirect/Get
      • POST로 주문 후에 웹 브라우저를 새로고침하면?
      • 새로고침은 다시 요청
      • 중복 주문 가능성
    1. 클라이언트: 요청
    POST /order HTTP/1.1   # <- POST 사용
Host: localhost:8080

itemId=mouse&count=1
    1. 서버: 주문데이터 저장
      2.1. DB에 mouse 1개 등록
    2. 서버: 응답
    HTTP/1.1 200 OK

<html>주문완료</html>
    1. 여기서 사용자가 새로 고침을 할 경우!!
      클라이언트: 요청
    POST /order HTTP/1.1  # <- 또 POST사용!!!!
Host: localhost:8080

itemID=mouse&count=1
    1. 서버: 다시 주문데이터 저장
      5.1. DB에 mouse 1개 등록
    2. 서버: 응답
    HTTP/1.1 200 OK

<html>주문완료</html>
    • 결국 새로고침 때문에, 클라이언트는 2번 요청한다. (너무 당연하겠지만..)
      • 이 문제를 해결하기 위해 POST 주문 후에, 결과화면을 GET메서드로 리다이렉트
      • 새로고침해도 결과 화면을 GET으로 조회
    1. 클라이언트: 요청
    POST /order HTTP/1.1   # <- POST 사용
Host: localhost:8080

itemId=mouse&count=1
    1. 서버: 주문데이터 저장
      2.1. DB에 mouse 1개 등록
    2. 서버: 응답
    HTTP/1.1 302 Found          # <- 200 OK가 아니고 302 Found 및 
Location: /order-result/19  # <- Location 보냄
    1. 이럴 경우 사용자 클라이언트는 302 Found를 응답받았으므로, Location를 찾을 것이고
      거기로 임시 Redirect한다.
    GET /order-result/19   # <- GET으로 위 서버의 응답의 Location으로 요청
Host: localhost:8080

itemID=mouse&count=1
    1. 서버: 다시 주문데이터 저장
      5.1. DB에 mouse 1개 등록
    2. 서버: 응답
    HTTP/1.1 200 OK

<html>주문완료</html>

    4xx : 클라이언트 오류

    • 오류의 원인이 클라이언트에 있음: 4xx대
      • 클라이언트 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음
    • 클라이언트가 이미 잘못된 요청을 하기 때문에, 똑같은 재시도가 실패 할 것
    상태 코드설명추가 설명
    400Bad Request클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
  • 요청 구문, 메시지 등등 오류
  • 클라이언트는 요청 내용을 다시 검토하고, 보내야함
  • 예) 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때
    • 401Unauthorized클라이언트가 해당 리소스에 대한 인증이 필요함: 인증(Authentication) 되지 않음
  • 401 오류 발생 시, 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명
  • 참고
    • 인증(Authentication): 본인이 누구인지 확인(로그인)
    • 인가(Authorization): 권한 부여(admin 권한처럼, 특정 리소스에 접근할 수 있는 권한
      인증이 있어야 인가가 있음)
    • 오류 메시지가 Unauthorized 이지만 인증 되지 않음(이름이 아쉬움)
    403Forbidden서버가 요청을 이해했지만, 승인을 거부함
  • 요청 리소스가 서버에 없음
  • 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때
  • 즉, 서버가 클라이언트한테 리소스를 보여주고 싶지 않을 때
    • 404Not Found요청 리소스를 찾을 수 없음
  • 요청 리소스가 서버에 없음
  • 또는 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때

    • 5xx : 서버 오류

    • 오류의 원인이 서버에 있음: 5xx대
      • 서버 문제로 오류 발생
      • 서버에 문제가 있기 때문에, 재시도하면 성공할 수도 있음
    상태 코드설명추가 설명
    500Internal Server Error서버 문제로 오류 발생
    503Service Unabailable서비스 이용 불가
  • 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
  • Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있음

    • html

    출처:https://aboooks.tistory.com/210

    profile
    markyang92
    pllpokko@alumni.kaist.ac.kr
    이전 포스트

    django

    다음 포스트

    html

    0개의 댓글