[HTTP] HTTP 메서드

🌳 HTTP API

🍃 API URI 설계

다음과 같이 짜는게 좋은 URI일까?

    ▪ 회원 목록 조회: read-member-list

    ▪ 회원 조회: read-member-by-id

    ▪ 회원 등록: create-member

    ▪ 회원 수정: update-member

    ▪ 회원 삭제: delete-member

 

URI에서 Resource의 의미는 뭘까?

회원을 등록하고 수정하고 조회하는 것 X, 회원 그 자체가 리소스 O

따라서 등록/수정/조회라는 기능 모두 필요 없고, 회원이라는 리소스만 식별하게 하면 된다.

* 참고로 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용을 권장한다. (member X, members O)

 

이런 도출로 다시 URI를 짜보면, 

    ▪ 회원 목록 조회: /members

    ▪ 회원 조회: /members/{id}

    ▪ 회원 등록: /members/{id}

    ▪ 회원 수정: /members/{id}

    ▪ 회원 삭제: /members/{id}

 

하지만 이렇게 매핑한다면 어떻게 기능들을 구별할 수 있을까?

리소스와 행위를 분리하여 리소스는 URI로 작성하고 행위는 HTTP 메서드를 통해 나타내자

리소스는 명사 역할을, 행위는 동사 역할을 하는 애라고 보면 된다. (ex. 리소스: 회원, 행위: 등록/수정/조회/삭제)

 

🌳 HTTP 메서드

🍃 GET

: 리소스 조회

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

서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달한다.

메시디 바디를 사용해서 데이터를 전달할 수 있으나, 지원하지 않는 곳이 많기 때문에 쓰지 않는 것이 좋다.

 

GET 예시

1. 서버에 조회를 위한 GET 메서드 HTTP 메시지 전달

2. 서버는 {id} 또는 query에 맞는 리소스 찾는다.

3. 클라이언트에게 응답 데이터 전달 (ex. 200 OK)

 

🍃 POST

: 요청 데이터 처리 (주로 등록에 사용)

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

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

메시지 바디를 통해 서버로 요청 데이터를 전달하면 서버는 요청 데이터를 처리한다.

메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.

주로 신규 리소스 등록, 프로세스 처리에 사용한다.

 

POST를 사용하는 상황

1. 새 리소스를 등록해야 하는 경우

2. 프로세스 처리와 같은 요청 데이터를 처리해야 하는 경우

    예를 들어, 결제완료->배달시작->배달완료와 같이 프로세스 상태가 변경될 때 사용한다.

    그러나 이와 같은 경우 리소스만 가지고 무슨 일을 해야 할 지 식별이 불가능하기 때문에 역할도 URI에 포함시켜야 한다. (최대한 지양)

    역할이 포홤된 다음과 같은 URI를 컨트롤 URI라고 부른다. (POST /orders/{orderId}/start-delivery)

3. 다른 메서드로 처리하기 애매한 경우 (ex. JSON으로 조회 데이터 넘기고 싶을 때)

 

POST 예시

1. 서버에 신규 등록을 위한 POST 메서드 HTTP 메시지 전달

2. 서버는 메시지 바디에 들어있는 내용을 통해 리소스를 등록한 후 신규 리소스 식별자를 생성

3. 클라이언트에게 신규 리소스 식별자가 포함된 응답 데이터를 전달 (ex. 201 Created)

 

🍃 PUT

: 리소스를 대체, 해당 리소스가 없으면 생성 (수정이 아니라 "대체"!)

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

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

쉽게 생각하면 덮어쓰기 기능이라고 생각하면 된다.

"덮어쓰기"라는 역할에 주목해야 하는데, 완전히 대체해버리기 때문에 기존의 데이터는 그냥 증발해버린다!

예를 들어, username과 age 필드 중에 age만 값을 전달하게 된다면 username의 값은 사라진다.

또 다른 중요한 점은 클라이언트가 리소스를 식별해야 한다는 것이다.

클라이언트가 리소스 위치를 알고 URI를 지정해야 한다. (POST와의 차이점)

 

PUT 예시

1. 서버에 PUT 메서드 HTTP 메시지 전달

2. 서버는 URI에 있는 리소스 식별자를 통해 이미 있으면 덮어쓰고 없으면 생성한다.

 

🍃 PATCH

: 리소스 부분 변경

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

{
    "age":20
}

PUT과 달리 "일부"만 변경하고 싶을 경우에는 PATCH를 사용하면 된다.

 

🍃 DELETE

: 리소스 삭제

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

 

🍃 기타 메서드

    ▪ HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환

    ▪ OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)

    ▪ CONNECT: 대상 자원으로 식별되는 서버에 대한 터널을 설정

    ▪ TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

 

🌳 HTTP 메서드의 속성

1. 안전(Safe)

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

 

2. 멱등(Idempotent)

: 몇번을 호출하든 결과가 똑같다. 

    ▪ POST의 경우 두 번 호출하면 같은 결제가 중복해서 발생할 수 있기 때문에 결과가 똑같지 않다.

외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다. (GET->PUT->GET X)

서버가 타임아웃 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가? 에 대한 판단 근거가 된다.

 

3. 캐시 가능

: 응답 결과 리소스를 캐시해서 사용해도 되는가?

GET, HEAD 정도만 캐시로 사용 가능하며 POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데 구현이 쉽지 않다.

 

 

 

---

참고자료

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의