[모든 개발자를 위한 HTTP 웹 기본지식] 04- Http 메서드

1. HTTP 만들어보기 

요구사항 -> 회원 정보 관리 API를 만들어 보자 (진짜 백엔드 x, 개념적 설계 o)

기능 요구사항 -> 회원 목록 조회/ 회원 조회 / 회원 등록 / 회원 수정 / 회원 삭제 

기능에 따른 API URI 설계 

• 회원 목록 조회/ read-member-list
• 회원 조회/ read-member-by-id
• 회원 등록/ create-member
• 회원 수정/ update-member
• 회원 삭제/ delete-member

-> 이건 좋은 URI 설계가 아님 

1-1. API의 URI (Uniform Resource Identifier)설계시 고려사항 

resource 란 회원 등록, 수정, 조회가 아니다. 회원이라는 개념 자체가 바로 리소스 이므로 리소스 식별은 회원을 등록하고 수정하고 조회 등등을 모두 배제하고 회원이라는 리소스를 식별하는 것에 집중한다. 따라서 회원 리소스를 URI에 매핑한다. 

-> URI 재설계 (리소스 식별 집중/ URI 계층 구조 활용)

• 회원 목록 조회/ members
• 회원 조회/ members/{id}
• 회원 등록 / members/{id}
• 회원 수정/ members/{id}
• 회원 삭제/ / members/{id}

회원은 여러명이므로 복수형 , 계층 구조를 적용해 다음엔 회원 Id를 배치, 하지만 조회, 등록, 수정,삭제 기능을 URI 만으로 구별할 수 없다는 문제가 발생한다. 

 

-> 리소스와 행위를 분리 

URI는 리소스 식별에만 집중하고 리소스와 해당 리소스를 대상으로 하는 행위를 분리한다. (리소스 -> 회원, 행위 -> 조회, 등록, 삭제, 수정) 행위를 구분하기 위해 사용되는 HTTP method에 대해서 정리해보자.

 

2. HTTP method

1. GET : 리소스 조회
   1. 서버에 전달하고 싶은 데이터를 쿼리를 통해 전달한다.
   2. 메시지 바디를 이용할 수는 있지만, 지원하지 않는 곳이 많지않아 권장하지 않는다. 
   3. 클라이언트가 서버에 request message 전달 -> 서버가 클라이언트로 response message 전달 
2. POST : 요청 데이터 처리, 주로 등록에 사용
   1. message body를 통해 server로 request data 전달 
   2. server는 request data 처리 
   3. 미리 약속된 URL 로 POST method에 따른 message를 전달하면, message body에 실려온 데이터를 이용해 자원을 추가한다던가 특정 process를 수행하는 등의 작업을 진행한다. 
   4. [post 정리]
      1. 새로운 리소스 생성 ( 등록) : 서버가 아직 식별하지 않은 새로운 리소스를 생성
      2. 요청 데이터 처리 : 단순히 데이터를 생성하거나, 변경을 넘어 새로운 프로세스를 처리하는 경우 
      3. 최대한 자원을 계층화해서 표현하려 하지만, 동사를 URI 설계에 포함할 수 밖에 없는 경우가 발생하고, 이를 control URI라 부른다. 보통 컨트롤 URI는 POST method로 처리한다. :POST/orders/{orderId}/start-delivery
      4. 다른 메서드로 처리하기 애매한 경우 사용 
3. PUT : 리소스 전체를 대체, 해당 리소스가 없는 경우 생성
   1. 이미 존재하는 리소스 대체, 존재하지 않는 리소스의 경우 새롭게 생성 (덮어쓰기) 
   2. 이미 존재하는 리소스에 클라이언트가 PUT method를 이용한 request를 보내는 경우 덮어 씌운다. 
   3. PUT은 리소스를 제공된 정보를 바탕으로 완전히 대체하기 때문에, 기존에 리소스에 저장된 정보는 사라지게되고, 이는 제공하지 않은 필드에 대해서는 삭제함을 의미한다. 이러한 부분을 보완하기 위해 PATCH method를 사용한다. 
4. PATCH : 리소스의 일부를 변경
5. DELETE : 리소스 삭제 
6. HEAD : get과 동일하지만 HTTP message의 body 부분을 제외하고, header와 status line 만 반환
7. OPTIONS: 대상 리소스에 대한 통신 가능 옵션을 설명
8. CONNECT,TRACE: 이 두가지는 거의 사용 x

 

3. HTTP method 속성

http method는 다음과 같은 명칭들로 속성에 대한 정의가 가능하다. 

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

3-1. 안전 (Sage Methods)

호출해도 리소스를 변경하지 않는 method를 정의 

아무리 리소스 변경이 없어도, 계속 호출하여 로그가 쌓여 오류가 발생해도 안전하다고 판단? -> 안전 속성은 해당 리소스만 고려하기 때문에 그런 부분까지는 고려하지않는다. 

 

3-2. 멱등 (Idempotent Methods)

호출해도 결과가 똑같은 method를 정의하는 개념이다. 

[멱등 메서드]

• GET : 한 번 조회하든, 백번 조회하든 결과는 같음
• PUT : 결과를 대체하는 메서드, 따라서 같은 요청을 여러번 보내도 결과는 같다.
• DELETE : 리소스를 삭제하는 메서드 , 여러번 요청 보내도 한번만 삭제됨
• POST 는 멱등이 아니다. 

멱등이라는 속성은 자동 복구 메커니즘이나 서버가 TIMEOUT등으로 정상 응답을 못한 경우, 클라이언트가 같은 요청을 다시 해도 되는지에 대한 판단의 근거로 삼을 수 있다. 

재 요청 중간에 다른 곳에서 리소스를 변경해도 멱등인가?-> 멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려하지 않고 판단한다. 

 

3-3. 캐시 가능 (Cacheable Methods)

응답 결과 리소스를 캐시해서 사용해도 되는가? -> GET, HEAD, POST, PATCH 가능 

실제로는 GET,HEAD 정도만 캐시 사용 -> POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 이는 구현이 까다롭기 때문,

 

---

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 수강하면서 정리한 내용입니다.

 

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