[HTTP] 웹 기본 지식 정리 - HTTP 메서드

- 이 게시글은 인프런 "모든 개발자를 위한 HTTP 웹 기본지식"의 김영한님 강의를 보고 요약한 내용입니다.

---

1.  HTTP API 만들기

 

API URI 설계에 있어서 가장 중요한 것은 URI 계층 구조 활용과 리소스 식별 !

 

ex) 회원 정보 관리 API를 설계

- 회원 목록 조회

- 회원 조회

- 회원 등록

- 회원 수정

- 회원 삭제

▶ 회원이라는 개념 자체가 리소스이다.

 

리소스와 행위를 분리

- URI는 리소스만 식별

- 리소스는 명사, 행위는 동사

ex) 리소스 : 회원, 행위 : 조회, 등록, 삭제, 수정 등

 

행위를 어떻게 구분하는가? HTTP 메서드인 GET, POST ! 

 

2. HTTP 메서드 - GET, POST, PUT, PATCH, DELETE

 

주요 메서드(간단 요약, 자세한 정리는 아래에)

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에서 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성 ex) 폴더에 파일을 넣기
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

 

 

기타 메서드

• HEAD : GET과 동일하지만 메시지 바디 부분 제외(시작라인과 헤더만 반환함)
• OPTIONS : 주로 CORS에서 사용
• CONNECT : 거의 사용하지 않음
• TRACE : 거의 사용하지 않음

 

1 ) GET

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(query parameter, query string)를 통해 전달
• 메시지 바디를 사용해 데이터 전달 가능 → But, 지원하지 않는 곳이 많아 권장하지 않음

 

리소스 조회 메커니즘

GET /members/100 HTTP/1.1
Host: localhost:8080

→ 클라이언트에서 GET 방식으로 메시지 전달

 

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

→ 서버에 메시지가 도착하면 /members/100의 데이터를 찾아 JSON 형식의 메시지를 만듦

* JSON 형식일 수도 있고 아닐 수도 있음

 

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 34

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

→ 서버에서 응답 메시지를 만들어 클라이언트에게 보냄

 

2 ) POST 

POST /members HTTP/1.1
Content-Type: application/json

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

• 요청 데이터를 처리
• 메시지 바디를 통해 서버로 데이터 전달
• 서버는 요청 데이터를 처리 - 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
• 주로 전달된 데이터는 신규 리소스 등록, 프로세스 처리에 사용

 

리소스 등록 메커니즘

POST /members HTTP/1.1
Content-Type: application/json

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

→ 클라이언트가 서버에게 POST 방식으로 /members 로 메시지로 전달

 

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

→ 서버에서 전달 받은 데이터로 신규 리소스 식별자 생성(/members/100)

* 신규 등록으로 가정

 

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 34
Location: /members/100

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

→ 서버에서 응답 메시지를 만들어 클라이언트에게 보냄

* 자원이 생성된 경로(Location)도 보내줌

 

POST는 어떻게 요청 데이터를 처리한다는 뜻인가?

* 기능 사용 예시

- html form에 입력한 정보로 회원가입, 주문

- 게시판 글 쓰기, 댓글 달기

- 신규 주문 생성

- 한 문서 끝에 내용 추가하기

 

▶ 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할 지 리소스마다 정해야 함

→ 즉, 정해진 것은 없다.

 

POST 정리

- 서버가 아직 식별하지 않은 새 리소스 생성(등록)

- 요청 데이터 처리

• 프로세스를 처리해야 하는 경우
• 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
• POST 결과로 새로운 리소스가 생성되지 않을 수도 있음
• 리소스 단위로 URI 설계가 힘든 경우, 컨트롤 URI 사용 ex) POST/orders/{orderId}/start-delivery

 

- 다른 메서드로 처리하기 애매한 경우

• 메시지 바디에 조회용 데이터를 넘겨야 할 경우, GET 방식이 사용 불가능할 때(지원하지 않는 곳 다수)

 

▶ 애매하면 POST 사용 !

▷ But,  조회할 땐 최대한 GET 사용 → 캐싱을 위해

* POST 사용 시 캐싱이 어려울 수 있음

 

3 ) PUT

PUT /members/100 HTTP/1.1
Content-Type: application/json

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

• 리소스를 대체 - 리소스가 없으면 생성하고 있으면 대체 → 덮어쓰기 형식
• 클라이언트가 리소스 식별 ! - 클라이언트가 리소스 위치를 알고 URI 지정 → POST와 차이점

 

리소스 대체 메커니즘

PUT /members/100 HTTP/1.1
Content-Type: application/json

{
    "username": "old",
    "age": 50
}

→ 클라이언트가 서버에게 PUT 방식으로 /members/100 지정해서 데이터 전달

 

① 이미 리소스가 있는 경우

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

→ /members/100에 이미 존재하는 리소스

 

{
    "username": "old",
    "age": 50
}

→ /members/100에 리소스 대체

 

② 리소스가 없는 경우

{
    "username": "old",
    "age": 50
}

→ /members/100에 신규 리소스 생성

 

▶ 주의 ! - 리소스를 완전히 대체하므로 부분 변경이 불가능

부분 변경을하고 싶을 경우에는? PATCH 이용

 

4 ) PATCH

PATCH /members/100 HTTP/1.1
Content-Type: application/json

{
    "age": 50
}

• 리소스 부분 변경
• 지원 안되는 서버가 있을 경우, POST 사용

 

리소스 부분 변경 메커니즘

PATCH /members/100 HTTP/1.1
Content-Type: application/json

{
     "age": 50
}

→ 클라이언트가 서버에게 PATCH 방식으로 /members/100 지정해서 데이터 전달

 

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

→ /members/100에 이미 존재하는 리소스

 

{
    "username": "young",
    "age": 50
}

→ age만 50으로 부분 변경

 

5 ) DELETE

DELETE /members/100 HTTP/1.1
Host: localhost:8080

• 리소스 제거

 

리소스 제거 메커니즘

DELETE /members/100 HTTP/1.1
Host: localhost:8080

→ 클라이언트가 서버에게  /members/100 DELETE 요청

→ 해당 리소스 제거

 

3. HTTP 메소드의 속성

 

1 ) 안전(Safe)

 

- 호출해도 리소스를 변경하지 않는다.

- 안전은 해당 리소스만 고려

 

2 ) 멱등(Idempotent)

 

- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과는 똑같다.

- 멱등 메서드

• GET : 여러번 조회해도 같은 결과 조회
• PUT : 결과 대체, 같은 요청 여러번해도 최종 결과 동일
• DELETE : 결과 삭제, 같은 요청 여러번해도 삭제된 결과 동일
• POST : 멱등이 아님 !! 두 번 호출하면 중복해서 발생

- 활용 : 자동 복구 메커니즘

ex ) DELETE 호출했을 때, 서버에 응답이 없을 경우 → 클라이언트가 재시도 → 멱등이므로 여러번 호출해도 OK

 

▶ 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지 고려하지 않는다 !

 

3 ) 캐시 가능(Cacheable)

 

- GET, HEAD, POST, PATCH 캐시 가능

- 실제로는 GET, HEAD 정도만 캐시로 사용 - 캐시 키를 고려해야하기 때문에