[HTTP] 4. HTTP 메서드

안녕하세요!

오늘은 HTTP 메서드를 공부하고 내용을 정리해보았습니다.

시작해볼게요 고고!!

---

1. HTTP API를 만들어 보자. (과정)

1-1. 요구사항 - 회원 정보 관리 API를 만들어라!

• 회원 목록 조회
• 회원 조회
• 회원 등록
• 회원 수정
• 회원 삭제

 

1-2. API URI 설계

URI = Uniform Resource Identifier

• 회원 목록 조회: /read-member-list
• 회원 조회: /read-member-by-id
• 회원 등록: /create-member
• 회원 수정: /update-member
• 회원 삭제: /delete-member

URI 설계 후에 개발을 합니다.

 

그런데 여기서 한 가지 의문점이 있습니다.

이것은 과연 좋은 URI 설계일까요?

정답은 NO!

 

가장 중요한 것은! 리소스 식별을 기준으로 해야 한다는 것입니다.

 

1-2(1). API URI 고민

리소스란 무엇일까요?

리소스란 회원을 등록하고 수정하고 조회하는 등의 행위를 뜻하는 것이 아닙니다.

예를 들어 "강아지를 산책시켜라"라는 문장이 있습니다.

여기에서 리소스는 산책시켜라가 아닌 강아지가 됩니다.

즉, 회원이라는 개념 자체가 리소스라는 것입니다.

 

그럼 리소스를 어떻게 식별하는게 좋을까요?

회원을 등록하고 수정하고 조회하는 등의 행위는 모두 배제하고 회원이라는 리소스만 식별하면 됩니다.

즉, 회원 리소스를 URI에 매핑하면 된다는 뜻입니다.

 

1-2(2). API URI 설계

• 회원 목록 조회: /members
• 회원 조회: /members/{id}
• 회원 등록: /members{id}
• 회원 수정: /members/{id}
• 회원 삭제: /members/{id}

이렇게 회원을 기준으로 설계해야 합니다.

URI 계층 구조 활용해서 회원은 여러 명이니까 복수 단어인 members로 사용하였습니다.

 

그런데 보면 아시다시피 회원 조회부터 회원 삭제까지 /members/{id}로 다 똑같습니다.

이거 어떻게 구분할까요?

 

그래서 우리는 리소스와 행위를 분리해야 합니다.

아까 위에서 얘기한 URI는 리소스(회원)만 식별하는 것이 맞습니다.

그리고, 리소스와 해당 리소스를 대상으로 하는 행위를 분리해야 합니다.

• 리소스: 회원 (명사)
• 행위: 조회, 등록, 삭제, 변경 (동사)

이런 식으로 말이죠.

그럼 이 행위(메서드)는 어떻게 구분할까요?

이 질문에 대해서 해결을 하기 위해 우리는 HTTP 메서드라는 것을 사용합니다.

---

2. HTTP 메서드 종류

2-1. 주요 메서드 (GET, POST, PUT, PATCH, DELETE)

• GET: 리소드 조회
• POST: 요청 데이터 처리, 주로 등록에 사용
• PUT: 리소스를 대체, 해당 리소스가 없으면 생성 (파일을 폴더에 넣을 때와 비슷)
• PATCH: 리소스 부분 변경 (ex. 회원의 이름 변경 같은거..?)
• DELETE: 리소스 삭제

 

2-1(1). GET

GET은 리소스를 조회하는 메서드 입니다.

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

또한, 메시지 바디를 사용해서 데이터를 전달할 수는 있지만, 지원하지 않는 곳이 많아서 권장하지는 않습니다.

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

GET이 정확히 어떤 메서드인지 그림을 통해서 설명해보겠습니다.

 

• 리소스 조회1 - 메시지 전달

클라이언트가 id가 100번인 학생의 데이터를 조회해달라고 서버에게 요청합니다.

 

• 리소스 조회2 - 서버 도착

요청한 메시지가 서버에 도착했습니다.

 

• 리소스 조회3 - 응답 데이터

서버가 id가 100번인 학생의 데이터를 클라이언트에게 전달해서 응답한 것을 확인할 수 있습니다.

이런 행위를 하는 메소드를 GET이라고 합니다.

 

 

2-1(2). POST

POST는 요청 데이터를 처리하는 메소드 입니다.

GET과 다르게 메시지 바디를 통해 서버로 요청 데이터를 전달하고, 서버는 요청 데이터를 처리합니다.

POST의 대표적인 특징은 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다는 것입니다.

그리고, 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리(변경된 프로세스 바꿈 등)에 사용합니다.

 

꿀팁!!

애매하거나 이게 뭐지? 싶으면 왠만하면 POST 입니다.

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

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

POST가 정확히 어떤 메서드인지 그림을 통해서 설명해보겠습니다.

 

• 리소스 등록1 - 메시지 전달

클라이언트가 이름이 song이고 나이가 20살인 학생의 데이터를 등록해달라고 서버에게 메시지를 전달(요청)합니다.

 

• 리소스 등록2 - 신규 리소스 생성

신규 리소스 식별자(/members/100)를 생성해서 클라이언트로부터 데이터를 받아 처리합니다.

 

• 리소스 등록3 - 응답 데이터

서버가 신규 리소스 식별자(/members/100)에 학생의 데이터가 등록되었다고 클라이언트에게 메시지를 전달합니다.

 

 

POST는 중요한 점이 많기에 예시와 정리본을 정리하겠습니다.

먼저, POST는 요청 데이터를 어떻게 처리한다는 뜻일까요?

 POST는 다음과 같은 기능에 사용합니다.

(예시 위주로 보시면 됩니다)

 

1. HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공

ex) HTML FORM에 입력한 정보로 회원 가입, 주문 등에서 사용

2. 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시

ex) 게시판 글쓰기, 댓글 달기

3. 서버가 아직 식별하지 않은 새 리소스 생성

ex) 신규 주문 생성

4. 기존 자원에 데이터 추가

ex) 한 문서 끝에 내용 추가하기

 

결국 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다는 것입니다.

왜냐하면 정해진 것이 없기 때문이죠.

 

POST 최종적으로 정리해보겠습니다.

 

<POST 메서드가 하는 일>

1. 새 리소스 생성(등록)

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

 

2. 요청 데이터 처리

- 단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우

- ex) 주문에서 결제 완료 -> 배달 시작 -> 배달 완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우

 

- POST의 결과로 새로운 리소스가 생성되지 않을 수도 있습니다.

- ex) POST /orders/{orderId}/start-delivery (컨트롤 URI)

 

이 예시에서 굵은 글씨인 start-delivery 부분을 보면 분명 리소스는 명사가 온다고 했는데 동사가 왔습니다.

이런 동사의 URI를 컨트롤 URI라고 하고, 이런 경우에는 새 리소스가 생성되지 않아도 POST를 사용해야 합니다.

 

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

- ex) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

=> 조회라 원래 GET인데 메시지 바디의 내용을 전달해야하는 경우에는 메시지 바디를 지원하지 않는 곳이 많아서 이런 애매한 경우에는 POST를 사용합니다.

 

 

2-1(3). PUT

PUT은 대표적으로 2가지 특징이 있는 메서드 입니다.

 

첫 번째로, 리소스를 대체(완전히)하는 역할을 합니다.

리소스가 있으면 대체하고, 리소스가 없으면 생성하는 역할을 합니다.

쉽게 말해서 파일 복사처럼 기존 파일이 있으면 덮어쓰고 기존 파일이 없으면 생성한다는 의미입니다.

 

두 번째로, 클라이언트가 리소스를 식별한다는 것입니다.

클라이언트가 리소스의 위치를 알고 URI를 지정한다는 뜻이고, 이건 PUT만의 특징입니다.

 

POST와의 차이점을 설명하자면...

POST는 클라이언트가 리소스의 위치가 100번인지 200번인지.. 모릅니다.

그런데, PUT은 클라이언트가 리소스의 위치를 알아서 URI를 지정합니다.

 

PUT /members/100 HTTP/1.1
Content-Type: application/json
{
     "username": "ssari",
     "age": 25
}

PUT이 정확히 어떤 메서드인지 그림을 통해서 설명해보겠습니다.

 

• 리소스가 있는 경우1

기존 /members/100에는 이름이 song이고 나이가 20살인 학생의 데이터가 들어있습니다.클라이언트가 /members/100에 이름이 ssari이고 나이가 25살인 학생의 데이터로 대체하라고 서버에게 요청합니다.

 

• 리소스가 있는 경우2

서버가 /members/100의 리소스를 클라이언트에서 요청한 리소스로 대체했습니다.

 

 

• 리소스가 없는 경우1

서버에는 이전 리소스가 없습니다.

클라이언트가 /members/100에 이름이 ssari이고 나이가 25살인 학생의 데이터로 대체하라고 서버에게 요청합니다.

 

• 리소스가 없는 경우2

서버가 신규 리소스를 생성하였습니다(대체된 데이터 들어가있음).

 

 

• 주의!! - 리소스를 완전히 대체1

기존 /members/100에는 이름이 song이고 나이가 20살인 학생의 정보가 들어있습니다.

클라이언트가 /members/100에 있는 학생의 정보에서 이름 필드 없이 나이만 25살로 대체(수정)하라고 서버에게 요청합니다.

 

• 주의!! - 리소스를 완전히 대체2

/members/100에 있던 기존 데이터가 다 날라가고 클라이언트에서 요청한 나이 25살 리소스로 대체되었습니다.

 

 

2-1(4). PATCH

PATCH는 리소스를 부분만 변경할 때 사용하는 메서드 입니다.

PATCH가 가장 최근에 생긴 메소드여서 만약에 PATCH를 지원을 안 할 경우에는 POST를 사용하면 됩니다.

PATCH /members/100 HTTP/1.1
Content-Type: application/json
{
     "age": 25
}

PATCH가 정확히 어떤 메서드인지 그림을 통해서 설명해보겠습니다.

 

• 리소스 부분 변경1

클라이언트가 /members/100 리소스에서 나이만 25살로 바꿔달라고 서버에게 요청합니다.

 

• 리소스 부분 변경2

클라이언트에서 요청한 대로 이름은 그대로 놔두고 나이만 25살로 변경하였습니다.

 

 

2-1(5). DELETE

DELETE는 리소스를 제거하는 메서드 입니다.

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

 DELETE가 정확히 어떤 메서드인지 그림을 통해서 설명해보겠습니다.

 

• 리소스 제거1

클라이언트가 id가 100번인 리소스를 제거해달라고 서버에게 요청합니다.

 

• 리소스 제거2

/members/100 리소스가 제거되었습니다.

 

 

2-2. 기타 메서드

• HEAD: GET과 동일하지만 메시지 부분(메시지 바디) 제외하고 상태 줄과 헤더만 반환합니다.
• OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명합니다. (주로 CORS에서 사용)
• CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정합니다. (거의 사용X)
• TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행합니다. (거의 사용X)

---

3. HTTP 메서드의 속성

3-1. 안전 (Safe)

• 호출해도 리소스를 변경하지 않습니다.
  • Q. 계속 호출하다가 로그 같은게 쌓여서 장애가 발생한다면?
  • A. 안전은 해당 리소스만 고려하기 때문에 그런 부분까지 고려하지 않습니다.
• GET, PUT, PATCH, DELETE는 안전O / POST는 안전X

 

3-2. 멱등 (Idempotent)

• f(f(x)) = f(x) => 한 번 호출하든 여러번 호출하든 결과가 똑같다는 뜻입니다.
• 멱등 메서드
  • GET: 한 번 조회하든, 여러번 조회하든 같은 결과가 조회됩니다. (똑같은 정보 계속 조회해봤자 똑같음)
  • PUT: 결과를 대체합니다. 따라서 같은 요청을 여러번 해도 최종 결과는 같습니다. (똑같은 파일 계속 업로드해도 아예 날리고 덮어쓰는 과정을 반복하기에 계속 똑같음)
  • DELETE: 결과를 삭제합니다. 따라서 같은 요청을 여러번 해도 삭제된 결과는 같습니다.
  • POST: 멱등이 아닙니다. 왜냐하면 두 번 호출하면 같은 결제가 중복해서 발생할 수 있기 때문입니다. (만약에 사장이 배송을 2번 누르면 문제가 일어남)
• 활용
  • 자동 복구 메커니즘
  • Q. 서버가 TIMEOUT 등으로 정상 응답을 주지 못했을 때, 클라이언트가 같은 요청을 다시 해도 되는가?
  • A. 멱등이면 괜찮습니다.
• Q. 재요청 중간에 다른 곳에서 리소스를 변경해버리면?
  • 사용자1: GET -> username:A, age:20 (조회)
  • 사용자2: PUT -> username:A, age:40 (중간에 대체해버림)
  • 사용자1: GET -> username:A, age:40 => 사용자2의 영향으로 바뀐 데이터 조회(처음 조회할 때랑 다름)
• A. 멱등은 외부 요인으로 인해 중간에 리소스가 변경되는 것 까지는 고려하지 않습니다. 서버가 알아서 체크하도록!

 

3-3. 캐시 가능 (Cacheable)

위의 2개의 개념보다 더 중요한 개념입니다. (자세한 설명은 나중에..)

• Q. 응답 결과 리소스를 캐시해서 사용해도 되는가?
• A. GET, HEAD, POST, PATCH는 캐시 가능합니다.
• BUT, 실제로는 GET, HEAD 정도만 캐시로 사용합니다.
  • POST, PATCH는 본문 내용까지 캐시 키로 고려(똑같은 캐시 키여야 함)해야 하는데 구현이 쉽지 않기 때문입니다.