HTTP(2/3)

HTTP Method 속성

HTTP Method는 안전성(Safe), 멱등성(Idempotent), 캐시가능성(Cacheable) 속성을 가지고 있다.

• Optional은 Java의 Optional과 같이 있을 수 있다라는 말과 같다.

1. 안전성(Safe)
   
   
   • GET 메소드(조회)는 안전하다.
     • 저장된 데이터를 변환하지 않는다.
   • POST, DELETE, PUT, PATCH는 안전하지 않다.
     • 데이터를 생성, 수정, 삭제한다.
       
       
       
2. 멱등성(Idempotent)
   
   
   • 한번을 호출하거나 수천번을 호출하거나 항상 결과는 같다.
     1. GET → 같은 결과가 계속 조회된다.
     2. PUT → 수정해서 대체된 후의 결과는 계속 같다.
     3. DELETE → 같은 요청을 여러번해도 삭제된 결과는 같다.
     4. POST → 멱등성을 보장하지 않는다.
        
        
   • 요청이 실패한 경우 재시도 하기위해 필요하다.
     1. 항상 결과가 같다면 마음껏 재시도 해도된다.
     2. 만약 멱등하지 않다면, 중복 요청을 보내서는 안된다.
     3. 복구 매커니즘에 사용한다.
        
        
   • 리소스 조회(GET Method) 재요청 중간에 변경된다면?
     재요청 중간에 리소스가 변경되는것은 멱등성으로 고려하지 않는다.
     
     
     
     
3. 캐시가능성(Cacheable)
   
   
   • 재사용을 위해 요청에 대한 응답을 저장할 수 있는가?
     1. GET, HEAD, POST 메소드는 캐시가 가능하다.
     2. 일반적으로 GET, HEAD 정도만 캐시로 사용한다.
        
        

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

HTTP 상태 코드

HTTP 요청에 대한 처리 상태를 응답하는 코드로 Data를 함께 응답한다. Spring에서는 Response를 커스텀하여 의미있는 메세지를 만들어 사용하기도 한다.

• HTTP Response Message 구조
  

HTTP Status Code

• 1xx (정보)

  • 요청 수신 후 처리중인 상태
  • 잘 사용하지 않는다.

• 2xx (성공)

  • 정상 처리 완료된 상태

• 3xx (리다이렉션)

  • 요청을 완료하려면 추가 행동이 필요한 상태
  • 3xx 응답 + Location HTTP Header가 있으면 Location 위치로 리다이렉트 한다.

• 4xx (클라이언트 에러)

  • 클라이언트측 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없다.
  • 클라이언트의 요청이 잘못되었기 때문에, 같은 요청의 재시도는 실패한다.

• 5xx (서버 에러)

  • 서버 오류, 요청은 정상이지만 서버가 처리하지 못함
  • 재시도하면 성공할 수 있다.

• 새로운 상태 코드가 추가되어도 변경할 필요가 없다.
• 디테일한 코드를 몰라도 몇 번대 코드인지만 알면 된다.
• 응답 코드를 상황에 맞게 잘 작성 해야 한다. 매우 기본이고 매우 중요하다.

HTTP API 설계

• HTTP API 설계 - 잘못된 예시

  • 게시글 생성
    • /create/board
  • 게시글 1개 조회
    • /read/board/1
  • 게시글 목록 조회
    • /read/board-list
  • 게시글 수정
    • /update/board/1
  • 게시글 삭제
    • /delete/board/1

• HTTP 1강 정리

  • URI
    • 리소스 식별자
  • HTTP Message
    • HTTP 통신에서 주고받는 데이터
  • HTTP Method
    • 처리할 행위

• HTTP API 설계 방법

  1. HTTP API는 설계시 항상 리소스 식별을 기준으로 삼아야한다.
  2. 위 예시에서 리소스는 게시글이다.
  3. URI에 들어갈 리소스는 단수 형태가 아닌 복수 형태로 사용을 권장한다. board → boards
  4. URL에 동사를 사용하지 않는다.
  5. HTTP Method의 역할을 URL에 포함하지 않는다.

• 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 (서버 문제)