[모든 개발자들을 위한 HTTP 웹 기본 지식] #4. HTTP 메서드

[seyxxn]

4_HTTP 메서드

HTTP API를 만들어보자

• URI 설계
  • 회원 목록 조회 / read-member-list
  • 회원 조회 / read-member-by-id
  • 회원 등록 / create-member
  • 회원 수정 / update-member
  • 회원 삭제 / delete-member
• 이것이 좋은 URI인가? 리소스 식별이 중요함

리소스

• 회원을 등록하고 수정하고 조회하는 것이 리소스가 X
• 회원이라는 개념 자체가 리소스
• 회원을 등록하고 수정하고 조회하는 것을 모두 배제
• 회원이라는 리소스만 식별하면 됨 -> 회원 리소스를 URI에 맵핑
• 리소스를 식별한 URI 설계
  • 회원 목록 조회 / members
  • 회원 조회 / members/{id}
  • 회원 등록 / members/{id}
  • 회원 수정 / members/{id}
  • 회원 삭제 / members/{id}
  • 참고 : 계층 구조상 상위를 컬렉션으로 보고 복수단어 사용 권장
  • 목록 조회를 제외한 URI를 어떻게 구분하는가?

리소스와 행위를 분리

• 가장 중요한 것은 리소스를 식별하는 것
• URI는 리소스만 식별
• 리소스와 해당 리소스를 대상으로 하는 행위를 분리
  • URI는 리소스만 식별해야지 리소스의 행위를 식별하지 않음
• 위의 예시에서
  • 리소스 : 회원 (명사)
  • 행위 : 조회, 등록, 삭제, 변경 (동사)

HTTP 메서드 - GET, POST

주요 메서드

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

기타 메서드

• HEAD : GET과 동일하지만 메세지 부분을 제외하고 상태줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명
• CONNECTS : 대상 리소스로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메세지 루프백 테스트를 사용
• CONNECTS, TRACE는 거의 사용하지 않음

GET

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

• 리소스 조회
• 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
• 메세지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않은 곳이 많아서 권장하지 않음

• 클라이언트가 GET 메서드를 이용하여 members/100 100번 유저의 정보를 달라고 요청

• 서버에서는 GET 메세지가 도착
• 서버에서 메세지를 까서보니, 100번 멤버의 정보를 달라는 것을 인지함
• 서버는 내부의 데이터베이스를 조회하여 응답 메세지를 만든다
• json 메세지를 만들어서 클라이언트에 보냄

• 클라이언트는 응답 데이터를 받음

POST

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

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

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

• 리소스를 일단 전달함

• 서버에서 받은 데이터를 열어봄
• 데이터베이스에 신규로 등록함

• 자원이 신규 생성된 URI를 응답 데이터로 보내줌

POST 정리

1. 새 리소스 생성(등록)
   • 서버가 아직 식별하지 않은 새 리소스 생성
2. 요청 데이터 처리
   • 단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야하는 경우
   • 예) 주문에서 결제완료 -> 배달 시작 -> 배달 완료 처럼 단순이 값 변경을 넘어 프로세스의 상태가 변경되는 경우
   • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있음
   • 예) POST /orders/{orderId}/start-delivery (컨트롤 URI)
   • start-delivery라는 행위를 URI로 하는 것은 좋지 않지만, 리소스만을 가지고 URI를 설계하기는 어렵기 때문에 사용하는 경우도 존재함 -> 이것을 컨트롤 URI라고 한다.
3. 다른 메서드로 처리하기 애매한 경우
   • 예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하지 어려운 경우
   • 애매하면 POST

HTTP 메서드 - PUT, PATCH, DELETE

PUT

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

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

• 리소스를 대체
  • 리소스가 있으면 대체
  • 리소스가 없으면 생성
  • 쉽게 이야기해서 덮어버림
• 중요) 클라이언트가 리소스를 식별
  • 클라이언트가 리소스 위치를 알고 URI 지정
    • /members/100 이렇게 보내기 때문에 클라이언트가 구체적인 리소스 전체 경로를 알고 있음
    • 이것이 POST와 차이점
    • POST는 몇번에 만들어질지 모름

• members/100 URL을 지정하여 요청 메세지에 데이터와 함께 넘기면
• 서버에는 이미 리소스가 존재함
• 이때는 대체가 됨

• members/100 URL을 지정하여 요청 메세지에 데이터와 함께 넘기면
• 서버에는 리소스가 존재하지 않음
• 이때는 신규로 생성이 됨

PUT에서는 리소스를 완전히 대체함

• username 필드를 넣지 않은 경우
  • PUT은 기존 리소스를 완전히 대체하기 때문에 기존에 존재하던 username 필드는 없어짐 (안보냈으니까)

PATCH

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

• 리소스 부분 변경

• username필드 없이 PATCH 메서드 사용
  
• age만 50으로 부분변경 됨

DELETE

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

• 리소스 제거

• members/100 100번 멤버를 지우겠다는 요청 메세지를 보냄
  
• 서버에서 그 멤버를 찾아 삭제

HTTP 메서드의 속성

• 안전
• 멱등
• 캐시 가능

안전 (Safe)

• 호출해도 리소스가 변경이 안됨
• get은 안전함
• 나머지 바꾸는 메서드들은 안전하지 않음
• Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생한다면 ?
• A: 안전은 해당 리소스에 대해서만 고려함. 그런 부분까지 고려하지 않음

멱등 (Idempotent)

• f(f(x)) = f(x)
• 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같은 것이 멱등이다.
• 멱등 메서드
  • GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
  • PUT : 결과를 대체한다.(완전히 덮는다) 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
  • DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
  • POST : 멱등이 아니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
• 활용
  • 자동 복구 메커니즘
  • 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때, 클라이언트가 같은 요청을 다시 해도 되는가?
    • 예 : DELETE를 했을 때, 서버에서 응답이 없어서 다시 DELETE를 요청한다. 해도 되는 것인지?
• Q: 재요청 중간에 다른 곳에서 리소스를 변경해버리면?
  • 사용자1 : GET -> username:A, age:20
  • 사용자2 : PUT -> username:A, age:30
  • 사용자3 : GET -> username:A, age:30 -> 사용자2의 영향으로 바뀐 데이터 조회
• A: 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않음

캐시 가능 (Cacheable)

• 응답 결과 리소스를 캐시해서 사용해도 되는가?
• GET, HEAD, POST, PATCH 캐시 가능
• 실제로는 GET, HEAD 정도만 캐시로 사용
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않음

---

🔗 출처

• 김영한 - 모든 개발자를 위한 HTTP 웹 기본 지식