[네트워크] HTTP 메서드

HTTP API를 만들어보자

왼쪽과 같은 요구사항이 들어왔다고 했을 때 URI설계를 오른쪽과 같이 하는건 좋지 않다.

가장 중요한건 리소스 식별이기 때문이다.

URI에서는 회원이라는 리소스만 식별하면 된다 -> 회원 리소스를 URI에 매핑한다!

 

따라서 이와 같이 설계하는 것이 좋다.

URI는 리소스만 식별 -> 행위는 어떻게 구분할까??

 

HTTP 메서드

HTTP 주요 메서드는 위와 같다.

 

GET

리소스를 조회한다.

서버에 전달하고 싶은 데이터는 쿼리를 통해서 전달한다.

바디는 거의 사용하지 않는다.(지원하지 않는 곳이 더 많아서..)

POST

요청 데이터를 처리한다.

메시지 바디를 통해 서버로 요청 데이터를 전달한다. 

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

POST는 저장할때만 쓰이지는 않는다.

 

POST를 사용하는 경우

• 새 리소스 생성(등록)
• 요청 데이터 처리(결제완료 -> 배달시작과 같이 상태 변경 프로세스에서 필요)
• 다른 메서드로 처리하기 애매한 경우(JSON으로 조회 메서드 넘겨야하는데 GET 메서드 사용하기 어려운경우)

이처럼 애매한 경우에도 POST를 쓴다.

POST/orders/{orderId}/startdelivery -> 상태 변경 URI

이 경우 URI에 리소스 정보만 담는다는 원칙을 위배하지만 어쩔 수 없으니 그냥 쓴다.

 

PUT

리소스를 대체한다. 만약 리소스가 없으면 생성한다.

POST와의 차이점은 클라이언트가 리소스의 위치를 알고있다는 점이다.(members/100)

 

주의할 점은 위와 같이 put메서드로 특정 필드를 제외하고 보내면

서버는 이를 그대로 받아들이고, 리소스를 대체하여 아예 제외한 필드가 사라지게 된다.

 

PATCH

이런 경우를 피하려면 patch메서드를 쓰면 된다. patch는 리소스를 부분 변경한다.

따라서 patch를 쓰면 username 필드를 넣지 않고, age 정보만 넣고 서버에 요청을 했더라도

username 필드는 사라지지 않고 age만 변경되는 것을 볼 수 있다.

 

DELETE

말 그대로 해당 리소스를 제거한다.

 

HTTP 메서드의 속성

안전

여기서의 안전이란 호출해도 리소스를 변경하지 않는 것을 의미한다.

(GET제외 모두!)

 

멱등

한번 호출하든, 두번 호출하든, 100번 호출하든 결과가 같다.

GET, PUT, DELETE는 멱등 메서드이다.

하지만 POST메서드는 멱등이 아니다!

 

멱등이 중요한 이유는 서버가 클라이언트에게 정상 응답을 주지 못했을 때 클라이언트가 같은 요청을 다시 해도 되는가?에 대한 판단 근거가 된다.

 

멱등성이 있다면 고려하지 않고, 그냥 한번 더 요청하면 된다!

 

캐시가능

응답 결과 리소스를 캐시해서 사용해도 되는가?
(여기서 캐시란 데이터를 브라우저에 저장해두는 것)

보통 GET, HEAD 정도만 캐시로 사용하고, POST, PATCH는 할수는 있는데 구현이 쉽지 않다.

 

출처

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard

모든 개발자를 위한 HTTP 웹 기본 지식 강의 | 김영한 - 인프런