[HTTP] HTTP 메서드

HTTP API를 만들어보자

 

아래와 같은 기능이 필요할 때 API URI를 설계해보자. 

- 회원 목록 조회

- 회원 조회

- 회원 등록

- 회원 삭제

 

/read-memeber-list

/create-member

등은 좋지 않은 설계이다.

API는 리소스 식별이 기준이 되어야 한다.

 

회원이라는 개념 자체가 리소스이다.

/members 와 같이 리소스만을 기준으로 설계하자.

 

조회/등록/삭제 등의 동작은 http 메서드를 통해 구분하자.

---

HTTP 메서드 - GET, POST

 

GET, POST가 http에서 가장 주요한 메서드이다.

 

GET

- 리소스 조회 시 사용

-  전달할 데이터는 쿼리파라미터를 통함

-  메시지 바디 사용은 권장하지 않음

 

POST

- 데이터 처리를 요청

- 메시지 바디를 통해 서버로 데이터 전달

- 서버에서 데이터 처리

- 주로 신규 리소스 등록, 프로세스 처리에 사용

- 정해진 것이 없음. POST 요청이 오면 리소스별로 처리를 다르게 함

- 다른 메서드로 처리하기 애매한 경우에도 사용됨 (바디가 필요한 조회 등)

---

HTTP 메서드 - PUT, PATCH, DELETE

 

PUT

- 리소스가 있으면 덮어쓰고 없으면 생성함

- 리소스 위치를 직접 지정함 (PUT /members/100 HTTP/1.1)

- 리소스를 완전히 대체함에 주의해야 함. 부분 업데이트 안 됨.

 

PATCH

- 리소스 위치를 지정함

- 리소스 부분 업데이트 가능

 

 DELETE

- 리소스 제거

---

HTTP 메서드의 속성

 

http 메서드에는 속성이 존재한다.

HTTP - 위키백과, 우리 모두의 백과사전 (wikipedia.org)

안전, 멱등, 캐시가능 등이 여기 해당한다.

 

안전

- 호출 시 리소스를 변경하지 않는다.

 

멱등

- f(f(x)) = f(x)

- 한 번 호출과 n번 호출에 차이가 없다.

- GET/PUT/DELETE는 멱등, POST는 멱등하지 않다. 결제와 같은 상황이 두 번 일어나면 장애가 있음

- 응답을 제대로 받지 못했을 때, 다시 요청해도 되는가? 등의 판단에 사용됨

 

캐시가능

- 응답 결과 리소스를 캐시해서 사용해도 되는가?

- GET/ HEAD/ POST/ PATCH 캐시가능하다 하지만 실제로는 GET 정도만 캐시로 사용.

  바디 등의 내용에 따라 달라져 구현이 쉽지 않기 때문이다.