HTTP 웹 기본 지식 - 3일차(HTTP 메서드)

이번엔 HTTP 메서드에 대해서 공부를 했다.(내가 제대로 알지 못했던 부분이 있어서 진짜 기초가 중요하다는 것을 다시 한번 알게 되었다.)

 

만약 회원 API를 만들라고 했을 때 URI 설계를 아래처럼 했다

 

회원 목록 조회 /read-member-list

회원 조회 / read-member-my-id

회원 등록 / create-member

회원 수정 / update-member

회원 삭제 / delete - member

 

이렇게 설계를 하는 것이 과연 좋은 설계일까?

-> 사실 이건 좋은 설계는 아니다

URI의 설계에서 가장 중요한 것은 리소스 식별이다. 즉 리소스의 의미를 담아야 한다

(리소스는 자원이다 미네랄을 캐라 라는 말에서 미네랄이 리소스이고 캐라 라는 단어는 행위이다)

 

그래서 이번에는 리소스의 의미를 담아서 URI를 설계했다.

회원 목록 조회 /members

회원 조회 /members/{id}

회원 등록 /members/{id}

회원 수정 /members/{id}

회원 삭제 /members/{id}

 

그런데 이렇게 설계를 하면 행위는 어떻게 구분을 할까? 

HTTP 메서드가 위 행위를 구분해 준다.

 

HTTP 메서드에는

• GET : 리소스 조회
• POST : 요청 데이터 처리, 주로 등록에 사용
• PUT : 리소스를 대체, 해당 리소스가 없으면 생성
• PATCH : 리소스 부분 변경
• DELETE : 리소스 삭제

이렇게 있도 또 추가로 4개가 더 있다 앞에 5개는 많이 중요한 것

• HEAD : GET과 동일하지만 메시지 부분 제외됨, 상태 줄과 헤더만 반환
• OPTIONS : 대상 리소스에 대한 통신 가능 옵션 설명(CORS에 사용)
• CONECT : 대상 리소스로 식별되는 서버에 대한 터널을 설정
• TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행

이렇게 추가적인 4개가 존재하는데 밑에 CONECT, TRACE는 거의거의 안 쓴다.

 

GET

리소스를 조회하는 역할

메시지 바디를  사용해서 데이터 전달을 할 수 있지만 거의 그렇게 안 하고 쿼리 파라미터나 쿼리 스트링을 사용한다

 

POST

데이터를 등록하라고만 알고 있는 사람들이 있는 게 그러한 역할만 있는 것이 아니다.(실제로 나도 이렇게만.. 알고 있었는데....)

요청 데이터를 처리하는 역할

메시지 마디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.

프로세스 처리에도 사용한다.(주문 -> 결제 -> 배달 시작)

POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함 (광범위하기 때문)

또한 POST는 만능이라고 생각하면 되는데,

JSON으로 조회 데이터를 넘겨야 하는데 GET 메서드를 사용하기 어려운 경우에도 쓰일 수 있다. 그냥 애매하면 다 POST를 쓴다.

 

(추가* 위에서 URI 설계할 때는 리소스의 의미를 담아야 한다고 했지만 실무에서는 이걸 준수하기 어려움 그럴 때 다른 동사(행위)를 붙여서 URI를 설계하는데 이러한 방식을 컨트롤 URI라고 한다.)

 

PUT & PATCH

리소스를 대체한다 리소스가 있으면 대체하고 없으면 생성한다 쉽게 말해서 덮어버리는 걸로 알고 있으면 된다(난 여태까지 수정하는데 쓰이는 거라고 알고 있었다.. 내가 잘 몰랐지...)

PUT과 POST에 차이점으로는 PUT은 클라이언트가 리로스의 위치를 정확하게 알고 URI를 지정한다.

POST로 서버 요청 URI가 /members 로 적혀있음

PUT 서버요청 URI가 /members/100 으로 적혀있음

여기서 주의해야 할 점은 리소를 완전히 대체한다는 것이다.

위 그림처럼 age만 PUT으로 보내면 

이처럼 된다.

그럼 만약 age만 부분적으로 변하게 하려면 어떻게 해야 할까?

바로 PATCH 메서드를 사용하면 된다. 그럼 age만 50으로 변하게 된다.

 

PUT에서 PATCH가 따로 생긴 거라고 볼 수 있다. 그런데 만약 PATCH가 지원이 안되면 어떻게 해야 할까? 그냥 POST를 쓰면 된다 (POST 무적)

 

DELETE

말 그대로 리소스를 제거하는 것이다.

 

 

이제 HTTP 메서드 속성에 대해서 알아보자

HTTP 메서드 속성에는 3가지가 있다.

• 안전(safe Methods)
• 멱등(Idempotent Methods)
• 캐시가능(Cacheable Methods)

 

안전

호출해도 리소스가 변경하지 않는 것을 말한다.

이때 안전은 해당 리소스만 고려하고 로그가 쌓여서 장애가 발생한다는 이런 거는 고려하지 않는다.

 

멱등

똑같은 요청을 보내도 결과가 같은 것을 말한다(1번 호출, 2번 호출, 100번 호출해도 결과가 똑같다는 말 이때 요청은 같은 조건으로 요청했을 때이다.)

멱등이 어디에 활용되냐면 자동 복구 메커니즘에 활용된다

이게 무슨 말이냐면, 예를 들어서 클라이언트가 딜리트를 보냈을 때, 서버에 반응이 없을 때 클라이언트가 딜리트를 한번 더 보내도 된다. 이러한 것을 자동 복구 메커니즘이라고 한다. 

멱등은 외부 요인으로 중간에 리소스가 변경되는 것은 고려하지 않는다(여러 요청 중에 중간에 다른 사용자가 값을 바꿨을 때 이건 고려하지 않겠다는 말이다.)

 

캐시가능

응답 결과 리소스를 캐시 해서 사용해도 되는가를 따지는 것이다.

GET, HEAD, POST, PATCH가 캐시가능하다. 그러나 보통 GET, HEAD만 캐시로 사용된다. 그러한 이유는 POST, PATCH는 메시지 바디까지 캐시 키로 고려해야 하는데 이 구현이 쉽지 않기 때문이다.