[네트워크] HTTP API 설계에 대한 나름의 이해

URI의 핵심은 리소스를 식별이다.

리소스를 어떻게 할지에 대한 '행위'는 담으면 안된다!

 

미네랄을 캐라에서 미네랄은 리소스이고 캐라는 행위이다.

이걸 명백히 분리해야 한다.

URI에서는 리소스만 식별하고 행위는 HTTP 메소드가 한다!

이것이 좋은 설계이다

 

HTTP method에는 다음의 것들이 있다.

get

post

put

patch

delete

 

GET

조회할 때 사용한다.

캐싱이 가능하다.

query를 통해 데이터를 전달한다

바디에 데이터를 넣어 보낼 수도 있지만 지원이 안되는 서버가 많다.(비권장)

 

POST

사실상 바디에 데이터를 넣는 모든 행위에 사용가능하다

하지만 주로 데이터를 생성, 요청을 처리할 때 사용한다.

요청을 처리하는 경우 URI에 행위가 포함되어야 하는 경우가 발생한다. 예를 들어, start-delivery와 같이 자원과 행위가 모두 포함된다.

이러한 URI를 컨트롤 URI라고 한다.

다른 메소드로 처리하기에 애매할때도 POST를 사용한다. 예를 들어, JSON 데이터를 통해 데이터를 조회할 때 GET 대신 POST를 사용한다.

리소스가 생성되면 응답메시지의 start-line에 보통 Created라고 적어준다.

자원이 생성된 위치도 보내준다.

 

PUT

자원을 완전히 대체할 때 사용한다.

자원의 위치를 정확하게 알고 들어간다. 예를 들어, members/100이라는 정확한 위치에 들어간다. POST는 members까지만 안다.

완전히 대체하기 때문에 key, value를 명시하지 않은 데이터들은 날라가버린다.

 

PATCH

자원을 일부 수정할 때 사용한다.

PUT보다 나중에 나왔다.

역시 자원의 위치를 알고 들어간다. 하지만 key, value가 있는 부분만 대체해준다.

PATCH가 안되는 서버도 있을 수 있다. 이런 경우 POST를 사용하자. POST는 무적이다.

 

DELETE

자원을 삭제한다. 예를 들어, members/100을 삭제한다.

 

HTTP 메소드의 속성

1. 안전(Safe): GET, HEAD의 경우 자원을 변경하지 않기 때문에 안전한다. 한편 이런 메소드의 호출로 인해 쌓이는 로그들을 자원의 변경으로 보지 않는다.

2. 멱등(Idempotent): POST, PATCH를 제외한 메소드는 무한번 요청해도 결과가 같다. POST의 경우 결제를 두번 요청하는 등과 같은 경우가 생길 수 있다. 멱등의 필요성은 서버가 타임 아웃 등으로 제대로 응답을 못했을때 클라이언트가 다시 요청을 해도 문제가 생기지 않는 가에 있다. 따라서 자동 복구 메커니즘에 쓸 수 있다. 

멱등은 외부 요인으로 인해 자원이 변경되어 결과가 달라지는 것은 고려하지 않는다

3. 캐시 가능(Cashable): GET, HEAD, POST, PATCH는 캐시가 가능하다. 하지만 POST, PATCH는 body까지 key로 사용해야하기 때문에 구현이 어려워 잘 사용하지 않는다. GET, HEAD만 사용한다. HEAD는 잘 사용하지 않으니까 GET이 대부분 사용된다.