[인프런 김영한 강의 정리 - 인터넷과 http- ] - 4. HTTP METHOD

본 게시물은 인프런 강의(김영한 강사님의 '모든 개발자를 위한 http 강의)를 듣고 정리한 메모입니다. 

 

1. HTTP API 설계를 해보자.

URI : Uniform Resource Identifier. Resource에 맞추어서 API를 설계해야 한다.

회원 조회

회원 등록

회원 정보 변경

회원 삭제

 

→ 모두 Resource가 회원이므로

회원 조회 : /members

회원 등록 : /members{id}

회원 정보 변경 : /members{id}

회원 삭제 : /members{id}

→ 동사가 아니라(조회, 등록, 정보변경, 삭제 ) 명사로 적기.

→ 계층 구조상 상위를 컬렉션으로 보고서 복수 단어 사용을 권장한다. : mebers.

 

 

 

2. Resource에 관한 메서드들.

 a. GET

: 리소스 조회 : body에 데이터를 담을 수도 있지만 권장되지 않으며

 ?query parameter에 정보를 담아서 리소스 조회를 요청한다.

 리소스 조회대신 리소스를 처리하고 싶다면, 아래를 보자.

 

  b. POST

  리소스 처리: 사실 상 무적이라고 불린다 : 무엇을 할지 정해져 있지 않으며 리소스 별로 정해주어야 한다.

  따라서 리소스 처리라 함은 리소스를 다루는 모든 일을 의미하는 것이나 다름없다.

  하는 일 예시)

   1. 새 리소스 생성(등록)

   2. 프로세스 상태 변경 : /start-delivery 처럼 프로세스 상태를 URI로 사용하여 변경

       원래 URI는 명사를 사용하는 게 낫지만 어쩔 수 없이 동사를 사용하는 경우도 있다.

    3. 다른 메서드로 처리하기 어려운 경우(GET을 사용하면 캐싱이 가능해서 웬만하면 조회시엔 GET 사용하는 것이 좋다고 한다.)

        ex) JSON으로 조회데이터 넘기려고 하는데 GET 메서드 사용이 어려운 경우.

 

 

   c. PUT

     리소스 정보 대체, 없었다면 생성

     마치 파일을 저장할 때 같은 이름이 있다면 덮어쓰고 없다면 새 파일로 저장되는 것과 같은 원리이다.변경만 하려고 한 정보만 변경해서        PUT을 하려고 한다면, 나머지 정보는 사라질 것이다.

     이때 완전히 대체된다는 점이 중요하다:

     

   d. PATCH

    위 상황처럼 변경하려고 한다면 PATCH를 사용하는 것이 맞다.

    만약 PATCH가 지원되지 않는다면, 무적인 POST를 사용하도록 하자.

 

 

3. HTTP 메서드 속성

a.  안전

   리소스에 대해 메서드를 호출할 때 리소스가 변경되지 않는다면 안전하다.

   → GET은 안전하다. POST, PUT, DELETE 는 안전하지 않다.

b.  멱등

   리소스에 대해 동일한 메소드를 여러번 호출하더라도 결과는 동일하다.

   → GET, PUT, DELTE, PATCH는 멱등하다. POST는 멱등하지 않다. (매번 다른 프로세스로 전환 등)

c. 캐시 가능(Cacheable)

    리소스를 캐싱이 가능하다 : 이미지를 캐시화.

  → 키로 만들어놓는 것이기 때문에, GET, HEAD, PUT, PATCH가 모두 캐시 가능하지만, 키로 구현하는 것이 어려운 PUT, PATCH를 빼고 GET, HEAD를 주로 캐싱에 사용한다.