3 분 소요

HTTP 메서드

API URI를 설계할때 URI는 Uniform Resource Identifier 라는 말 그대로 리소스를 식별하는 용도로 사용하고 이 리소스에 대한 행위를 HTTP 메서드로 표현한다. 이 HTTP 메서드를 어떤식으로 사용해야할지 알아보자.

종류

GET

GET 메서드는 주로 리소스를 조회하는 용도로 사용한다. 메시지 바디를 이용하여 데이터를 전달할 수 있지만 지원하지 않는 곳이 많고 권장하지 않는다. 서버에 데이터를 전달하고자 할때 대부분 쿼리 파라미터를 통해서 전달한다.

GET /members/100

POST

POST는 요청 데이터를 처리하는 용도로 사용된다. 메시지 바디에 데이터를 넣어 서버로 전달한다. 서버는 메시지 바디를 통해 넘어온 데이터를 처리하는 기능을 수행한다. 주로 신규 리소스 등록, 프로세스 처리에 사용한다. 하지만 다른 메서드로 처리하기 애매한 경우 사용되기도 한다.

POST /members

PUT

리소스를 대체할때 사용된다. 기존에 해당 리소스가 있다면 전체가 대체되고(덮어쓰기 생각) 없다면 새로 생성이된다. 사용시 클라이언트가 리소스 위치를 알고 URI를 지정해야한다.

변경 전

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

적용

PUT /members/100

{
    "age":50
}

변경 후

{    
    "age":50
}

PATCH

PUT은 리소스를 완전히 덮어쓰는 형식으로 전체가 변경이 되었다면 PATCH는 리소스를 부분 변경한다.

변경 전

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

적용

PATCH /members/100

{
    "age":50
}

변경 후

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

DELETE

리소스를 제거할때 사용된다.

DELETE /members/100

GET 처럼 조회하는 용도로 사용하지만 메시지 부분은 제외하고, 상태줄과 헤더만 반환한다.

속성

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

GET, HEAD

멱등 : 한 번 호출하든 두 번 호출하든 몇 번을 호출해도 결과가 똑같다.

GET : 몇 번 조회해도 동일한 결과 조회

PUT : 신규 리소스일땐 등록되고 기존 리소스일때는 전체를 덮어써서 결국 결과는 동일하다.

DELETE : 몇 번을 호출해도 삭제된 결과는 동일하다.

POST : 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다. 멱등 아님

PATCH : 아래와 같은 형태는 멱등이지만 호출할때마다 age를 10씩 증가하는 형태의 경우처럼 멱등하지 않게 설계할 수 도 있다.

{
    "age":20
}

캐시가능 : 응답 결과 리소스 캐시 가능한지

GET, HEAD, POST, PATCH 모두 캐시 가능하지만 실제로는 GET, HEAD 정도만 사용한다.

사용 예시

  • 정적 데이터 조회
  • 동적 데이터 조회
  • HTML Form 통한 데이터 전송
  • HTTP API 통한 데이터 전송

정적 데이터 조회

이미지, 정적 텍스트 문서 같은 정적 데이터를 조회할 때 GET 메서드를 사용하고 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회한다.

GET /static/star.jpg

동적 데이터 조회

주로 검색, 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용한다. GET을 사용하며 쿼리 파라미터를 통해 데이터를 전달한다.

HTML Form 데이터 전송

HTML Form 의 경우 GET, POST 만 허용하며 GET 형식일때는 쿼리 파라미터로 POST 형식일 때는 메시지 바디로 데이터를 전송한다. POST 형식의 메시지 바디로 전송이 될때 데이터 형태는 쿼리 파라미터로 전송할때와 동일한 형태이다.(key1=value1&key2=value2)

GET, POST만을 지원하기 때문에 GET, POST의 기능만으로는 처리가 완벽하지 않다. 때문에 컨트롤 URI를 사용하는 경우가 많다. 예를 들면 회원 삭제의 경우 POST /members/{id}/delete 와 같은 형태로 동사로 된 리소스 경로를 사용하는 것이다.

HTTP API 데이터 전송

아래와 같은 경우 HTTP API 데이터 전송을 사용한다.

  • 서버에서 서버로 데이터 전송

  • 앱 클라이언트
    • 아이폰, 안드로이드
  • 웹 클라이언트
    • 자바 스크립트를 통한 통신(AJAX)

HTTP API 로 데이터 전송하는 경우 POST, PUT, PATCH(메시지 바디), GET(쿼리 파라미터) 모두 사용 가능하다. 또한 전송되는 데이터의 타입은 JSON이 많이 사용된다.(사실상 표준)

앞에서 확인한 것과 같이 다음과 같은 상황에 이런 메서드를 사용한다.

조회: GET

수정: PATCH, PUT, POST

삭제: DELETE

신규등록, 데이터 처리, 프로세스 처리: POST

POST vs PUT 데이터 등록

POST

클라이언트는 등록된 리소스의 URI를 모른다. 새로운 회원을 등록하는 경우를 생각해보자. 이 경우 다음과 같이 서버에게 메시지 바디의 내용만 전달하고 요청만 해주고있다.

POST /members

{"name":"kim", "age":20}

서버는 데이터를 받아 등록된 리소스 URI를 생성해주고 다음과 같이 클라이언트에게 응답을 보낸다.

HTTP/1.1 201 Created

Location: /members/100

컬렉션(Collection)

  • 서버가 관리하는 리소스 디렉터리
  • 서버가 리소스의 URI를 생성하고 관리
  • 위 예시에서 컬렉션은 /members 이다.

PUT

클라이언트는 리소스 URI를 알고있어야 하고 클라이언트가 직접 리소스 URI를 지정한다. 즉, 클라이언트가 생성될 리소스 URI를 알고 관리한다.

PUT /files/{filename}

스토어(Store)

  • 클라이언트가 관리하는 리소스 저장소
  • 클라이언트가 리소스의 URI를 알고 관리
  • 위 예시에서 /files

※ 보통 PUT 보다는 POST를 많이 사용한다. PUT은 파일 관리 시스템처럼 리소스 URI를 알고있는 경우 사용한다.

참고 개념

  • 문서(document)
    • 단일 개념(파일 하나, 객체 인스턴스, 데이터베이스 row)
    • /members/100
  • 컬렉션(collection)
    • 서버가 관리하는 리소스 디렉터리
    • 서버가 리소스의 URI를 생성하고 관리
    • /members
  • 스토어(store)
    • 클라이언트가 관리하는 저장소
    • 클라이언트가 리소스의 URI를 알고 관리
    • /files
  • 컨트롤 URI
    • 문서, 컬렉션, 스토어로 해결하기 어려운 프로세스 실행
    • 동사를 직접 사용
    • /members/{id}/delete
참고: [모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 강의 (inflearn.com)](https://www.inflearn.com/course/http-웹-네트워크)

댓글남기기

참고