[HTTP] HTTP Method

출처 

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

---

목차

 

HTTP API를 만들어보자

요구사항

회원 정보 관리 API를 만들어라

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

API URI 설계

(URI: Uniform Resource Identifier)

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

 

이것이 좋은 URI 설계일까?

X. 가장 중요한 것은 '리소스 식별' 

 

API URI 설계의 고민

• 리소스의 의미는 무엇일까?
  • 회원을 등록하고 수정하고 조회하는 것은 리소스가 아닙니다.
  • 예를 들어, 미네랄을 캐라 에서의 리소스는 미네랄입니다.
  • 즉, 리소스는 회원입니다.
• 리소스는 어떻게 식별하는 게 좋을까?
  • 회원을 등록하고 수정하고 조회하는 등의 행위는 모두 배제합니다.
  • 회원이라는 리소스만 식별가능하면 됩니다. 
  • 즉, 회원 리소스를 URI에 매핑합니다.

 

API URI 재설계

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

 

리소스를 식별하고 URI 계층 구조를 활용하여 재설계

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

참고 : 계층 구조상 상위를 컬렉션으로 보고 복수 단어 사용을 권장합니다. (members)

 

 

문제점

• 회원 목록 조회 : /members
• 회원 조회 : /members/{id}      → 어떻게 구분하지?
• 회원 등록 : /members/{id}      → 어떻게 구분하지?
• 회원 수정 : /members/{id}      → 어떻게 구분하지?
• 회원 삭제 : /members{id}       → 어떻게 구분하지?

 

리소스와 행위를 분리

• URI는 리소스만 식별하도록 설계합니다.
• 리소스와 해당 리소스를 대상으로 하는 행위를 분리합니다.
  • 리소스 : 회원
  • 행위: 조회, 등록, 삭제, 변경
  • 리소스는 명사, 행위는 동사 (ex) 미네랄을 캐라)
• 행위(메서드)는 어떻게 구분할까요? 이떄 사용되는 것이 HTTP Method 입니다.

 

 

HTTP 메서드 종류

주요 메서드

• GET : 리소스 조회
• POST : 요청 데이터 처리
• PUT : 리소스를 대체, 해당 리소스가 없다면 생성
• PATCH : 리소스 부분 변경 (특정 필드를 수정)
• DELETE : 리소스 삭제

기타 메서드

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

 

HTTP 메서드 - GET, POST

GET

 

• 리소스를 조회할 때 사용하는 메서드입니다.
• 서버에 전달하고 싶은 데이터는 Query(쿼리 파라미터, 쿼리 스트링) 을 통해서 전달합니다.
• 메시지 바디를 사용해서 전달할 수는 있지만, 지원하지 않는 곳이 많기 때문에 권장하지 않습니다.

 

리소스 조회 1. 메시지 전달

 

리소스 조회 2. 응답 데이터

 

POST

 

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

 

리소스 등록 1. 메시지 전달

 

리소스 등록 2. 신규 리소스 생성

 

리소스 등록 3. 응답 데이터

 

요청 데이터를 처리한다는 건 어떤 뜻일까?

표준 스펙에서는 POST 메서드를 다음과 같이 정의합니다.

POST 메서드는 대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청합니다. (구글 번역)

 

예를 들어 POST는 다음과 같은 기능에 사용됩니다.

• HTML Form 에 입력된 필드 데이터 블록을 데이터 처리 프로세스에 제공
  • ex) 회원 가입(예) ID, 비밀번호, 이메일 등), 주문
• 게시판, 뉴스 그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
  • ex) 게시판 글쓰기, 댓글 달기
• 서버가 아직 식별되지 않은 새 리소스 생성
  • ex) 신규 주문 생성
• 기존 자원에 데이터 추가
  • 한 문서 끝에 내용 추가

참고 : 주문 처리
온라인 쇼핑몰이나 결제 시스템과 같이 상품을 주문하고 결제하는 경우, POST 메서드를 사용하여 주문 정보를 서버로 전송할 수 있습니다. 서버는 해당 주문 정보를 사용하여 주문을 처리하고, 결제를 진행하고 배송 정보를 저장할 수 있습니다.

참고 : 파일 업로드
사용자가 웹 사이트나 애플리케이션에 파일을 업로드하는 경우, POST 메서드를 사용하여 파일 데이터를 서버로 전송할 수 있습니다. 서버는 해당 파일 데이터를 사용하여 파일을 저장하거나 처리할 수 있습니다.

 

결론

URI에 POST 요청이 오면 데이터를 어떻게 처리할 지 리소스마다 따로 지정해야 합니다. (따로 명확히 정해진 것이 없습니다.)

 

정리

1. 새 리소스 생성 (등록)
   • 서버가 아직 식별되지 않은 새 리소스를 생성
2. 요청 데이터 처리 ⭐
   • 단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
   • ex) 주문 프로세스 : 결제 완료 → 배달 시작 → 배달 완료 처럼 단순한 값 변경을 넘어 프로세스의 상태가 변경되는 경우 (서버에서 큰 변화가 발생한다.)
   • POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
   • 참고: URI를 설계할 때 리소스 단위로 설계하지 못하는 경우도 있다. (컨트롤 URI)
     • ex) 배달 시작 : POST /orders/{orderId}/start-delivery
3. 다른 메서드로 처리하기 애매한 경우
   • ex) JSON으로 조회 데이터를 넘기려고 하는데 쿼리 스트링 대신 메시지에 바디에 넘겨할 경우라서 GET 메서드를 사용하기 어려울 경우
   • 웬만하면 POST로 대체할 수 있지만, 조회할 때는 GET을 쓰는 것이 좋습니다. 서버가 GET으로 요청이 들어오면 캐싱을 하기 때문입니다.

 

HTTP 메서드 - PUT, PATCH, DELETE

PUT

•  

• 리소스를 대체하는 메서드입니다.
  • 리소스가 있으면 대체
  • 리소스가 없으면 생성
  • 쉽게 이야기해서 덮어버린다.
• 중요! 클라이언트가 리소스를 식별합니다.
  • 클라이언트가 리소스의 위치를 알고 URI을 통해 지정합니다.
  • POST와의 차이점입니다.

 

리소스가 있는 경우

 

 

 

 

리소스가 없는 경우

 

 

 

 

주의! 리소스를 완전히 대체한다.

 

 

 

 

PATCH

• 리소스를 부분으로 변경합니다.
• 가끔 Patch가 안되는 서버들도 있는데, 그럴 경우에는 Post를 쓰면 됩니다.

 

리소스 부분 변경

 

 

DELETE

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

 

리소스 제거

 

 

HTTP 메서드의 속성

• 안전(Safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)

안전 (Safe)

• 호출해도 리소스를 변경하지 않는 메서드들입니다.
• GET
• POST, PUT, DELETE, PATCH 모두 변경하므로 X

 

멱등 (Idempotent)

• f(f(x)) = f(x)

1. 동일한 작업을 여러 번 반복하더라도 결과가 동일하게 유지됩니다.
2. 작업의 순서가 바뀌더라도 결과가 동일하게 유지됩니다.

 

• 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같습니다.
• 멱등 메서드
  • GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
  • PUT : 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
  • DELETE : 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 같다.
• 멱등이 아닌 메서드
  • POST : 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
  • PATCH
    • 동일한 작업을 반복하더라도 결과가 동일하게 유지되는 특성에 위배됩니다.
      • ex) 사용자 이메일 주소를 'user@example.com'에서 'user@example.org'로 변경한다라는 패치를 두 번 적용하는 경우, 첫 번째 패치 적용 후에는 'user@example.org'로 변경되었기 때문에 두 번째 패치 적용 시에는 더 이상 변경이 발생하지 않으므로 패치의 일부가 변경된 경우 멱등성이 유지되지 않을 수 있습니다.
    • 작업 순서가 바뀌더라도 동일하게 결과가 유지되는 특성에 위배됩니다.
      • ex) 파일의 특정 라인을 'A'에서 'B'로 변경한다 라는 패치를 적용하고, 그 다음 파일의 특정 라인을 'B'에서 'C' 로 변경한다라는 패치를 적용하는 경우, 첫 번째 패치와 두 번째 패치의 순서에 따라 결과가 달라질 수 있으므로 시간에 따라 변경되는 패치의 경우 멱등성이 유지되지 않을 수 있습니다.
• 멱등 속성은 자동 복구 메커니즘에 활용됩니다.
  • 서버가 TIMEOUT등으로 정상 응답을 주지 못했을 때 클라이언트가 같은 요청을 다시 해도 되는가?의 판단 근거가 됩니다. (멱등 메서드는 가능.)

 

Q. 재요청 중간에 다른 곳에서 리소스를 변경한다면 GET이 멱등하지 않을 수도 있지 않나요?
    - 사용자 1: GET → username: A, age: 20
    - 사용자 2: PUT → username: A, age: 30
    - 사용자 3: GET → username: A, age: 30 → 사용자 2로 인해 바뀐 데이터

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

 

 

캐시 가능 (Cacheable)

참고 : 캐시
ex) 웹 브라우저에서 큰 용량의 이미지를 요청한다면?
또 같은 리소스를 서버에서 다시 가져올 필요가 없도록 로컬 PC의 웹 브라우저에 저장해놓는 것

 

• 응답 결과 리소스를 캐시하여 사용해도 되는가?
• GET, HEAD, POST, PATCH는 스펙상 캐시 가능합니다.
• 하지만, 실제로는 GET, HEAD 정도만 캐시로 사용합니다.
  • GET은 URI 만 Key를 잡고 캐시를 하면 되기 때문에 심플합니다.
  • POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 쉽지 않습니다.