HTTP 웹 기본 지식 - HTTP 메서드

API URI 설계

URI를 설계할 때 가장 중요한 점은 리소스 식별이다.

회원 조회, 등록, 수정, 삭제가 리소스가 아니라 회원 자체가 리소스이다.

그래서 회원 리소스를 URI에 매핑시킨다.

 

그렇다면 

회원 조회 : /members/{id}

회원 등록 : /members/{id}

회원 수정 : /members/{id}

회원 삭제 : /members/{id}

이렇게 나타낸다.

 

여기서 조회, 등록, 수정, 삭제를 어떻게 구분할까?

회원이라는 리소스를 가지고 어떠한 행위를 한다. 행위는 조회, 등록, 수정, 삭제를 의미한다.

리소스와 행위를 분리하는 것은 중요하다.

아무튼 여기서 이제 행위는 어떻게 구분할까?

--> HTTP 메서드 사용

 

---

HTTP 메서드

GET

저번에 배웠던 요청 메시지처럼 

GET 요청 메시지는 아래와 같이 생겼다.

/members/100에 어떤 자료가 있는지 조회하는 것이다.

 

물론 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 

지원하지 않는 곳이 많아서 권장하지 않는다고 한다.

 

그래서 응답 메시지는

위에서부터 start-line, header, message body로 나눠진 것을 볼 수 있다.

 

POST

요청 데이터를 처리하는 것이다.

메세지 바디를 통해 요청 데이터를 전달하면,

서버 입장에서 클라이언트가 POST를 보내면 내가 /members 이렇게 저장할거야 라는 식으로 약속을 한다.

 

POST 전달

서버가 요청 데이터 처리

위 사진은 메시지 바디를 통해 들어온 데이터를 /members/100 이라는 곳에 저장을 하는 것이다.

응답 메시지

 

PUT

PUT을 할 때, 리소스가 있으면 대체하고 없으면 생성을 한다.

파일 옮기는 것과 같다. 파일이 없으면 파일을 옮기고, 파일이 있으면 파일을 덮어쓰기 하는 것처럼 말이다.

 

클라이언트가 PUT 메서드 전송

여기서 중요한 점은 클라이언트가 리소스를 식별한다.

startline을 보면 POST와 다르게 /members/100 처럼 100을 지정한다. 

그래서 클라이언트가 POST와 다르게 리소스 위치를 알고 URI를 지정한다.

 

PUT을 하게 되면 위에서 말했다시피

지정한 URI에 리소스가 있다면 덮어씌우고, 없으면 해당 URI에 생성한다.

 

PATCH

patch는 put과 다르게 put은 완전히 대체하게 된다. 

하지만 patch는 부분 변경이 가능하다.

예로, 위의 PUT 예에서 

클라이언트가 위의 사진 처럼 요청하면

결과는

이렇게 되버린다. --> 완전히 대체

그러나 PATCH는

20에서 50으로 부분 변경이 된다. 

 

DELETE

지정한 URI에 있는 데이터를 삭제한다

 

---

HTTP 메서드 속성

안전

안전은 호출해도 리소스가 변경되지 않을 경우이다.

위에서 5가지 중에 GET만 안전하다고 볼 수 있다. 

왜냐하면 리소스가 변경되지 않기 때문이다.

 

멱등

멱등은 1번 호출하든 100번 호출하든 결과가 똑같다

GET, PUT, DELETE는 멱등 메서드이지만 POST는 멱등이 아니다.

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

POST를 하게 되면 데이터를 계속해서 추가할텐데, 데이터가 추가될 떄마다

당연히 다른 결과가 나타날 것이다.

 

---

 

출처 : 인프런 모든 개발자를 위한 HTTP 웹 기본 지식 (김영한 강사님)