HTTP API

HTTP API

API URI를 설계할 때 가장 중요한 것은 리소스 식별이다. 만약 회원을 등록, 수정, 조회하면 이때 리소스는 회원이라는 개념이다. 따라서 리소스를 식별하고 그 리소스를 대상으로 하는 행위를 분리하면 된다. 예를 들면 리소스는 회원이고 행위는 조회, 등록, 삭제, 변경이다.

메서드 종류

주요 메서드는 get, post, put, patch, delete가 있다. 자주 사용하지 않는 메서드로는 head, options, connect, trace가 있다. 

GET

get은 리소스를 조회할 수 있다. 보통 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)으로 전달을 한다.

get도 메시지 바디를 통해 데이터를 전달할 수 있지만 실무에서는 get에 body를 넣지 않는다.

POST

post는 요청 데이터를 처리할 수 있다. 메시지 바디를 통해 서버로 데이터를 전달할 수 있다. 주로 신규 리소스 등록, 프로세스 처리에 사용한다. 그리고 컬렉션 방식이라 서버가 새로 등록된 리소스 URI를 생성한다.

 

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

-서버에 아직 없는 새 리소스 생성

 

2. 요청 데이터 처리

-주문에서 "결제 -> 배달 시작 -> 배달 완료"처럼 상태가 변경되는 경우

-사실 리소스만으로 모든 URI를 설계하는 것은 어렵다. 그렇기에 "POST /orders/{orderId}/start-delivery" 이런 식으로 동사를 사용하는 컨트롤 URI로 사용할 수 있다.

 

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

-만약 get 메서드에서 메시지 바디를 보내고 싶으면 post로 보내는 것이 좋다. 이런 애매한 경우에서는 post를 사용하면 된다.

-하지만 get 메서드로 보낼 수 있다면 get를 사용해야 캐싱이 되어 좋다.

PUT

put은 리소스를 대체한다. 즉 수정하고자 하는 리소스를 아예 덮어써버린다. put과 post의 차이점으로는 put은 클라이언트가 리소스의 위치를 알고 URI를 지정한다는 점이다.

스토어 방식이라 클라이언트가 리소스의 URI를 알고 관리한다.

 

PATCH

patch는 리소스를 부분 변경한다. put은 아예 대체하지만 patch는 부분 수정이 가능하다.

DELETE

delete는 리소스를 제거할 수 있다.

HTTP 메서드의 속성

안전(Safe Methods)

아무리 많이 호출해도 리소스가 변경되지 않는 것을 안전하다고 한다.

get 메서드는 조회만 해서 안전하다고 할 수 있다.

멱등(Idempotent Methhods)

한 번 호출하든 100번 호출하든 결과가 똑같은 것을 말한다.

멱등 메서드로는 get, put, delete가 있다. put과 delete는 같은 요청을 여러 번 해도 최종 결과는 똑같다. 하지만 post는 멱등이 아니다. 결제 기능을 두 번 호출하면 2번 결제가 될 수 있기 때문이다.

멱등멱등 메서드는 요청했는데 서버에서 반응이 없어도 여러 번 보낼 수 있다. 그래도 결과는 같기 때문이다. 하지만 멱등 메서드가 아닌 것은 여러 번 요청을 보낼 수 없다.

캐시가능(Cacheable Methods)

get, head, post, patch는 캐싱이 가능하다. 하지만 실제로는 get, head 정도만 캐시로 사용한다. 왜냐하면 캐싱을 하기 위해서는 key가 맞아야 하는데 post와 patch는 key를 구현하기 쉽지 않기 때문이다.