HTTP - 메서드

in HTTP

1. API URI 설계

회원 목록 조회, 회원 조회, 회원 등록, 회원 수정, 회원 삭제가 있는 회원 정보 관리 API를 만든다고 했을 때 URI를 어떻게 설계해야 할까?

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

위와 같은 설계는 잘못된 설계이다. URI 설계에서 가장 중요한 것은 리소스 식별 이다. 회원 조회에서 리소스는 회원, 회원 등록에서 리소스는 회원, 회원 수정에서 리소스는 회원이다. 즉, 명사가 리소스이다. URI 설계에서는 리소스만으로 설계하고 리소스에 대한 행위 자체는 메서드가 구분하도록 만드는게 올바른 설계이다. 아래처럼 말이다.

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

조회는 GET, 등록은 PUT, 수정은 PATCH, 삭제는 DELETE 메서드로 구분해주면 된다. 위의 설계가 이상적이지만 실무에서는 리소스만으로 URI를 다 설계할 수는 없다. 기본적으로 리소스로 최대한 URI로 설계하되 어쩔수 없는 부분은 컨트롤 URI로 설계한다.

컨트롤 URI
/order/{orderid}/start-delivery

컨트롤 URI는 리소스만이 아니라 다른 부분이 추가된 URI라고 보면 된다. 예를 들면 HTML Form 태그에서는 POST, GET 방식만 사용할 수 있다. 따라서 조회를 제외한 나머지는 다 POST를 사용해야 한다. 그럼 전부 POST 방식으로 들어가면 구분할 수 없으니 거기다가 URI를 위 처럼 추가해 주는 것이다. 대부분 동사로 된 리소스 경로를 추가하게 되는데 예를 들면, POST 방식의 /NEW /EDIT /DELETE 정도가 있다.


2. 메서드 종류

주요 메서드

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

기타 메서드

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

기타 메서드는 그냥 이런게 있구나 정도만 알아두자.

GET

  • 리소스 조회
  • 서버에 전달하고 싶은 데이터는 query를 통해 전달
  • 메시지 바디를 사용해서 전달 가능하지만, 지원하지 않는 곳이 많으므로 메시지 바디를 사용하지 않는 것을 권장


POST

  • 메시지 바디를 통해 서버로 요청 데이터 전달
  • 서버는 요청 데이터를 처리하는데 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행
  • 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
  • 요청 데이터 처리에 사용
    • 데이터 생성, 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우 (결과로 새로운 리소스가 생성되지 않을 수 있음)
    • -> EX) 결제완료 -> 배달시작 -> 배달 완료 처럼 값 변경을 넘어서 프로세스의 상태 변경의 경우
  • 다른 메서드로 처리하기 애매한 경우에 POST 사용
    • 조회하려고 하는데 query가 아니라 메시지 바디에 조회 데이터를 넘기고 싶은 경우 POST를 사용(GET은 메시지 바디를 허용하나 권장하지 않기 때문)
  • 조회의 경우는 캐싱때문에 GET이 좋은 것일 뿐이지 사실 POST는 모든 작업을 다 수행할 수 있다. 따라서 리소스에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 한다.


PUT

  • 리소스 대체
    • 리소스가 없으면 생성, 있으면 대체
    • 대체라는 말은 그냥 덮어씌운다는 것 -> 갈아끼워버린다고 생각
    • 클라이언트가 리소스를 식별 -> 클라이언트가 리소스 위치를 알고 URI 지정
POST /members HTTP/1.1

PUT /members/100 HTTP/1.1

POST는 /members에 넣었는데 클라이언트는 서버에서 100번에 만들어질지 200번에 만들어질지 모른다. 이것은 서버에서 결정하는 것이다. 하지만 PUT의 경우는 딱 몇 번인지 지정한다. 즉, PUT의 경우 리소스를 정확히 알고 있다.
PUT은 리소스를 대체한다고 했다. 기존에 필드가 여러개 있었는데 수정하고자 메시지 바디에 한 개의 필드만 넣었다면 한 개의 필드가 수정되는게 아니라 기존에 있던 필드가 다 사라지고 그냥 방금 보내준 하나의 필드만 남게 된다. 갈아껴버린다고 생각하면 된다.


PATCH

  • 리소스 부분 변경 -> PUT처럼 갈아끼는게 아니라 부분만 변경
  • 대부분 지원하지만 지원하지 않는 경우 POST 사용


DELETE

  • 리소스 제거


3. 메서드의 속성

그림1

  • 안전 : 호출해도 리소스를 변경하지 않는다.
  • 멱등 : 한 번 호출하든 100 번 호출하든 결과가 같다.
    • 자동 복구 매커니즘에 활용
    • 서버가 정상 응답을 주지 못했을 때, 클라이언트가 같은 요청을 해도 되는가의 판단 근거
    • 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않는다. -> 자신이 같은 수행을 하는가만 고려
    • GET : 한 번 조회하든 100번 조회하든 같은 결과가 조회
    • PUT : 같은 요청을 여러번 해도 최종 결과는 같다.
    • DELETE : 같은 요청을 여러번 해도 삭제된 결과는 같다.
    • POST는 멱등이 아니다. 예시로 두 번 호출하면 중복 결제 발생
  • 캐시
    • GET, HEAD, POST, PATCH는 캐시가능하지만 실제로는 GET, HEAD 정도만 캐시 사용


4. HTTP 메서드 활용

클라이언트에서 서버로 데이터 전송

데이터 전달 방식

  • 쿼리 파라미터를 통한 데이터 전송
    • GET
    • 주로 정렬 필터(검색어)에 사용
  • 메시지 바디를 통한 데이터 전송
    • POST, PUT, PATCH
    • 주로 회원 가입, 상품 주문, 리소스 등록 변경에 사용

4가지 상황

  • 정적 데이터 조회
    • GET 방식
    • 쿼리 파라미터 없이 리소스 경로로 단순히 조회
  • 동적 데이터 조회
    • GET 방식
    • 쿼리 파라미터 사용해서 데이터 전달
  • HTML Form을 통한 데이터 전송
    • GET, POST 가능
    • GET 사용시 쿼리 파라미터로 데이터 전달
    • PSOT 사용시 메시지 바디를 통해서 key = value 형식으로 데이터 전달, 전송 데이터를 url encoding 처리
    • multipart/form-data로 파일 업로드 같은 바이너리 데이터 전송시 사용
  • HTTP API를 통한 데이터 전송
    • 서버끼리 통신할 때 사용 (서버끼리 통신할 때는 html같은게 없음)
    • 앱 클라이언트
    • 웹 클라이언트
    • POST, PUT, PATCH로 메시지 바디를 통해 데이터 전송
    • GET 조회로 쿼리파라미터 데이터 전달

POST와 PUT 기반 등록

  • POST 기반
    • 클라이언트는 등록될 리소스 URI를 모르며 서버가 새로 등록된 리소스 URI를 생성해준다.
    • 컬렉션 : 서버가 관리하는 리소스 디렉토리로 서버가 리소스의 URI를 생성하고 관리한다. 위에서는 /members 라고 보면 된다.
  • PUT 기반 등록
    • 클라이언트가 리소스 URI를 알고 있어야 하며, 클라이언트가 직접 리소스 URI를 지정한다.
    • 스토어 : 클라이언트가 관리하는 리소스 저장소로 클라이언트가 리소스 URI를 알고 관리한다.
      • 예를 들어 /files/{filename} 이라면 스토어는 /files
  • HTML FORM 기반
    • POST와 GET만 지원하는 제약이 있다. 이런 제약을 해결하기 위해 동사로 된 리소스 경로 컨트롤 URI를 사용


정리

  • HTTP API - 컬렉션
    • POST 기반 등록
    • 서버가 리소스 URI 결정
  • HTTP API - 스토어
    • PUT 기반 등록
    • 클라이언트가 리소스 URI 결정
  • HTML FORM 사용
    • GET, POST만 지원

대부분 컬렉션스타일을 사용하고 게시판이나 파일같은 경우 스토어 스타일을 사용하기도 한다.


© 2021. By Backtony