모든 개발자를 위한 HTTP 웹 기본 지식 ( 5 )

5. HTTP 메서드

 

HTTP API를 만들기

1. API URI 설계

현업에서 이렇게 설계를 많이 하지만 과연 좋은 설계인가? 

좋은 설계 : 리소스의 의미를 담아야 함

 

◆ API URI 고민 

 1) 리소스의 의미는 뭘까?

  : 회원을 등록, 수정, 조회하는게 리소스가 아니다. 

   ex) 미네랄을 캐라 -> 미네랄이 리소스이다   

  - 회원이라는 개념 자체가 리소스

    -> 회원 리소스를 URI에 매핑

    계층형구조 : /members/{id}

 

 ★ 리소스와 행위를 분리한다.

      회원       조회, 등록, 삭제, 변경

    URI는 리소스만 분리한다.

 

 

HTTP 메서드 - GET, POST

           GET - 무언가를 달라 / POST - 내가 데이터 줄게 등록하거나 처리해줘

            ◎ 용어번경 : 리소스 -> representation (표현) 으로 변경됨 

GET : 리소스 조회

POST : 요청 데이터 처리, 주로 등록에 사용

PUT : 리소스를 대체, 해당 리소스가 없으면 생성

                파일을 폴더에 넣는 것과 비슷 (동일한게 있으면 파일을 덮어쓰기 함)

PETCH : 리소스 부분 변경

DELETE : 리소스 삭제

 

*기타 메서드

HEAD : GET과 동일하지만 메세지 부분을 제외하고, 상태 줄과 헤더만 반환

            바디 빼고 헤더까지만 줘

OPTION : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명 (주로 CORS에서 사용)

(거의 사용X)  CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정

(거의 사용X) TRACE : 대상 리소스 경로 따라 메시지 루프백 테스트 수행

 

 

GET 

 

- 리소스 조회 

- /search?q=hello&hl=ko 이 url (path) 에 있는 자원을 주세요

- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링) 통해 전달

   (현업에서 X)  메시지 바디를 사용해서 데이터 전달 가능, 지원하지 않는 곳 많아 권장 X

 

 

POST 

 

(데이터 줄게 처리해줘)

- 요청 데이터 처리

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

- 서버는 요청 데이터를 처리

  ㆍ  메시지 바디 통해 들어온 데이터 처리하는 모든 기능 수행

   ex) 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

 

POST : 클라이언트 ----  /members  ---->  서버  : /members 로 오면 이거 신규로 등록할게라고 (행위를)미리 약속

이름/나이 보냄 -> 서버 : /members 보고 신규등록 해야하는구나. & 이름/나이 신규등록 -> 클라이언트 : 등록된 자원 받음

 

POST는 요청 데이터를 어떻게 처리한다는 뜻일까?

스펙- post 메서드는 대상 리소스가 리소스의 고유 한 의미 체계에 따라 요청에 포함 된 표현을 처리하도록 요청 

EX)

 html 폼 에서 회원가입, 주문

 게시판에 글쓰기

서버가 식별하지 않은  새 리소스 생성 (ex.신규 주문 작성)

 

[정리]

1. 새 리소스 생성, 등록

2. 요청 데이터 처리(생성, 변경, 처리)

   - 처리 : 결제 -> 배달시작 -> 배달완료    : 되게 큰 데이터 프로세스 처리하는 단계가 진행됨 이럴 때도 post사용.

   V post 결과로 새 리소스 생성되지 않을 수 있으나 서버에서 큰 변화 일어나는건 post 사용

   V 컨트롤URI ( orders/{orderId}/start-delivery ) 어쩔수 없이 써야할 때 있음.

 3. 다른 메서드로 처리하기 애매한 경우

   ex) get - 메세지 바디 잘 허용하지 않아 처리 안될 수 있음. -> 조회이지만 post 써야함. 

        이러면 메시지 body에 조회용 데이터를 넘기면 됨. 그러면 서버가 받아서 필요 값을 만들어서 씀

 ☆ POST는 모든 것 할 수 있음. but 조회는 get 쓰는게 좋음 (post는 캐싱이 어려움)

 

 

 

PUT

- 리소스를 대체 (있으면 완전히 대체)

★ 클라이언트가 리소스를 식별

 클라이언트가 리소스 위치를 알고 URI 지정. 

 

POST와 PUT의 차이점

POST	PUT
POST /members HTTP/1.1	PUT /members/100 HTTP/1.1
어디에 만들어질지 모름 (100? 200? )	100에 만들어짐. -> 클라이언트가 위치 100으로 지정 => 클라이언트가 리소스(위치)를 알고있다!

 

★ 리소스를 완전히 대체한다

 

PATCH

 

 

DELETE

 

(데이터 줄게 처리해줘)

 

 

 

HTTP 메서드의 속성

안전 (Safe Methods)

멱등 (Idempotent Methods)

캐시가능 (Cacheable Methods)

 

안전 (Safe Methods)

 - 호출해도 리소스를 변경하지 않는다.

   > 안전 : GET , HEAD

 - 계속 호출해서 로그 쌓여서 장애 발생하면? 이런건 고려하지 않음.

 

멱등 (Idempotent)

 - 한번 호출하든 두번호출하든 199번 호출하든 결과가 똑같다.

★ PUT 도 멱등이다!! (첫번째 덮음. 이후 동일)

    > 멱등 : GET , PUT , DELETE

  - POST는 멱등이 아니다 !! (같은 결제가 중복해서 발생할 수 있기 때문)

*멱등은 언제 쓰는가? 

  - 자동 복구 매커니즘 : delete 했는데 반응없음 -> 다시 delete 요청 (같은 결과이므로 다시 요청해도 괜찮음)

 *멱등이 안되는 케이스

  - 재요청 중간 리소스 변경해버리면?

     : 멱등은 외부요인으로 인해 변경되는것 고려 X. 

        내가 요청하는 것에 한해서 멱등 인정. (같은 호출자)

 

캐시가능 (Cacheable)

 - 응답 결과 리소스를 캐시해서 사용해도 되는가?

    > 캐시가능 : GET , HEAD , PETCH 

 - 실제로는 GET, HEAD 정도만 캐시로 사용 

   (POST, PETCH 는 본문 내용까지 캐시키로 고려해야 하므로 사용되지 않음 / 캐시하려면 키가 맞아야 함)