25.03.25 TIL - HTTP(2)

 

 

목차

 

 

HTTP

1. HTTP Method 속성

1) 안전성(Safe)

• GET 메소드(조회)는 안전함.
  • 저장된 데이터를 변환하지 않음.
• POST, DELETE, PUT, PATCH는 안전하지 않음.
  • 각각 데이터를 생성, 수정, 삭제함.

 

2) 멱등성(Idempotent)

• 한 번을 호출하거나 수천번을 호출하거나 항상 결과는 같음.
  1. GET → 같은 결과가 계속 조회됨.
  2. PUT → 수정해서 대체된 후의 결과는 계속 같음.
  3. DELETE → 같은 요청을 여러 번 해도 삭제된 결과는 같음.
  4. POST → 멱등성을 보장하지 않음.
• 요청이 실패한 경우 재시도 하기 위해 필요함.
  1. 항상 결과가 같다면 마음껏 재시도 해도 됨.
  2. 만약 멱등하지 않다면, 중복 요청을 보내서는 안됨.
  3. 복구 매커니즘에 사용함.
     • 요청 실패 시 서버에서 자동으로 재시도.
• 리소스 조회(GET Method) 재요청 중간에 변경될 경우
  • 재요청 중간에 리소스가 변경되는 것은 멱등성으로 고려하지 않음.
    • ex) 도서관 책 재고 조회(실시간으로 대여되는 경우)

 

3) 캐시가능성(Cacheable)

• 재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
  1. GET, HEAD, POST 메소드는 캐시 가능.
  2. 일반적으로 GET, HEAD 정도만 캐시로 사용함.
     • ex) 변경 가능성이 적은 정적자원(HTML, CSS, IMAGE, JS 등)을 주로 캐싱.

💡캐시(Cache)란?
    - 클라이언트가 서버에 한 번 요청했던 데이터에 대해서 매번 요청할 때마다 다시 전송할 필요가 없도록 웹 브라우저가 임시적으로 데이터를 보관하고 있는 장소.

 

 

2. HTTP 상태 코드

    - HTTP 요청에 대한 처리 상태를 응답하는 코드.

    - Data를 함께 응답함.

    - Spring에서는 Response를 커스텀하여 의미있는 메시지를 만들어서 사용하기도 함.

 

 

• 1xx (정보)
  • 요청 수신 후 처리중인 상태.
  • 잘 사용하지 않음.
• 2xx (성공)
  • 정상 처리 완료된 상태.
  • 대표 상태코드.
    • 200 OK
      • 요청 성공.
    • 201 Created
      • 새로운 리소스 생성.
    • 202 Accepted
      • 요청이 수신되었으나 처리가 완료되지 않음.
      • 주로 Batch 처리에서 사용됨.
        • ex) 설정한 시간마다 반복적으로 동작하는 특정 작업.
    • 204 No Content
      • 요청은 성공했지만, 응답 데이터가 없음.
        • ex) 저장, 작성 버튼 클릭 시.
• 3xx(리다이렉션)
  • 요청을 완료하려면 추가 행동이 필요한 상태.
  • 3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트.
  • 리다이렉션 종류
    • 300은 사용하지 않는다.
    • 영구 리다이렉션
      • URL이 영구적으로 변경된 경우, 기존 URL을 사용하지 않음.
      • 301 Moved Permanently
        • 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음.
      • 308 Permanent Redirect
        • 리다이렉트 시 요청 메서드와 본문 유지.
    • 일시 리다이렉션
      • URI가 일시적으로 변경된 경우
        • ex) 게시글 작성 후 게시글 목록 페이지로 이동, PRG 패턴.
      • PRG(Post, Redirect, Get) 패턴이란?
        • 게시글 작성(Post) → 응답(Redirect) → 리다이렉트 요청(Get)
      • PRG 패턴을 적용하지 않을 경우
        • 새로고침 시 요청이 중복으로 처리됨.
      • PRG 패턴을 적용할 경우
        • 새로고침을 하면 GET 요청을 함.
      • 대표 상태코드
        • 302 Found
          • 요청 메서드가 GET으로 변할 수 있음.
          • 모호해서 명확한 303, 307이 등장.
          • 이미 사용하고 있는곳이 많음. GET으로 변해도 상관없다면 사용해도 무방.
        • 303 See Other
          • 요청 메서드가 GET으로 변경됨.
        • 307 Temporary Redirect
          • 리다이렉트시 요청 메서드와 본문이 유지됨.
    • 기타 리다이렉션
      • 캐시를 활용할 것인지에 대한 여부
      • 대표 상태코드
        • 304 Not Modified
          • 캐시 목적으로 사용.
          • 리소스가 수정되지 않았다는 뜻, 클라이언트가 캐시된 데이터를 조회하도록 유도.
          • 응답에 바디가 있으면 안됨.
  • 4xx (클라이언트 에러)
    • 클라이언트측 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음.
    • 클라이언트의 요청이 잘못되었기 때문에 같은 요청의 재시도는 실패.
    • 대표 상태코드
      • 400 Bad Request
        • 클라이언트가 HTTP 요청 내용을 수정 후 보내야 함.
        ex) GET 메소드로 만들어진 API인데 POST로 보낸다?
        ex) API 스펙과 일치하지 않을 때, 숫자를 문자로, 문자를 숫자로.
      • 401 Unauthorized
        • 클라이언트가 리소스에 대한 인증(Authentication) 필요.
        • 응답에 WWW-Authenticate 헤더와 함께 인증 방법 설명.
        ex) 로그인
      • 403 Forbidden
        • 서버가 요청을 받았지만 승인 거부.
        • 주로 인가(Authorization) 관련문제.
        ex) 일반 유저, 관리자
      • 404 Not Found
        • 요청한 리소스가 서버에 없음.
        • 이를 이용하여 리소스를 숨겨놓기도 함
  • 5xx (서버 에러)
    • 서버 오류, 요청은 정상이지만 서버가 처리하지 못함
    • 재시도하면 성공할 수 있음.
      • ex) 서버가 일정시간 다운되었다가 다시 살아난 경우
    • 실제 서버에서 문제가 발생한 경우 5xx Error이기 때문에 발생하지 않는 것이 최선.
    • 대표 상태코드
      • 500 Internal Server Error
        • 대부분 500으로 처리.
      • 503 Service Unavailable
        • 서비스 이용 불가.
        • Retry-After Header를 사용하면 얼마뒤에 복구되는지 응답할 수 있음.

 

아직까지는 200, 201, 400, 404, 500 정도를 많이 접하는 것 같다.

 

3. 올바른 HTTP API 설계

• 게시글 생성
  • POST
  • /boards
  • 성공시 상태코드 2xx
  • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
• 게시글 1개 조회
  • GET
  • /boards/{id}
  • 성공시 상태코드 2xx
  • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
• 게시글 목록 조회
  • GET
  • /boards
  • 성공시 상태코드 2xx
  • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
• 게시글 수정
  • PUT or PATCH
  • /boards/{id}
  • 성공시 상태코드 2xx
  • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)
• 게시글 삭제
  • DELETE
  • /boards/{id}
  • 성공시 상태코드 2xx
  • 실패시 4xx (클라이언트 문제) OR 5xx (서버 문제)