Section 4. HTTP 메서드

1) HTTP API를 만들어보자

2) HTTP 메서드 - GET, POST

3) HTTP 메서드 - PUT, PATCH, DELETE

4) HTTP 메서드의 속성

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

1) HTTP API를 만들어보자

리소스(회원)을 중심으로 설계했는데 조회, 등록, 수정, 삭제는 어떻게 구분하지 ? ->HTTP 메서드

리소스와 메서드(행위)는 분리되어야한다. URI는 리소스만!!!!!!   리소스는 명사, 매서드는 동사

-----------------------------------------------------------------------------------------------------------------------------------------

 

2) HTTP 메서드 - GET, POST

리소스가 최근에는 Representation으로 바뀌었다.

 

 

 

#GET : 리소스 조회, 캐싱한다, 메시지바디는 거의 쓰지 않는다.

 

 

#GET의 처리과정

 

#POST

 

 

#POST의 처리과정

 

 

#POST

 

 

 

#POST는 모든 것을 할 수 있다.

 

URI는 리소스(명사)로 설계하라 했지만 어쩔 수 없는 부분이 반드시 존재. 이 부분의 경우 Control URI (=동사로된 URI)로 설계한다.

 

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

3) HTTP 메서드 - PUT, PATCH, DELETE

 

#PUT : 폴더에 파일을 넣는 것과 동일 ( 있으면 -> 삭제 후 생성(덮어쓰기), 없으면 -> 생성)

 

 

#POST에서는 /members 에 추가하지만 PUT은 /members/100 에 추가한다.

= PUT은 클라이언트가 리소스위치를 알고 있다. 

 

#PUT은 리소스를 완전히 대체한다. = age: "50"만 보냈을 때 username: "young", age: "20" 이 있었다면 age: "50"으로 완전히 대체된다. (username: "young" 삭제됨 = 전체 삭제 후 생성)

 

 

#PATCH : 리소스를 부분 변경한다. (가끔 지원안하는 서버도 있음)

  age: "50"만 보냈을 때 username: "young", age: "20" 이 있었다면 username: "young", age: "50"으로 부분변경된다.

 

 

 

#DELETE

 

#DELETE 처리과정

 

 

표는 참고

 

-----------------------------------------------------------------------------------------------------------------------------------------

 

4) HTTP 메서드의 속성

 

 

#안전 : 호출해도 리소스를 변경하지 않는다. (로그 쌓여서 장애는 고려 X) 

   - 호출을 해도 해당 리소스가 변하냐 변하지 않느냐

   - GET : 안전 ( 조회만 하고 리소스 변경하지 않는다. )

     POST, DELETE, PUT, PATCH : 호출했을 때 변경이 일어나므로 안전X 

 

#멱등 : f(f(x))=f(x) , 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.

   - 멱등 : GET, PUT, DELETE

   - 멱등X : POST

 

#멱등의 활용

: ex) DELETE 했는데 서버에서 응답 없으면 클라이 언트가 다시 요청 해도 되는지? 의 판단 근거 ( 자동복구메커니즘 )

 

#멱등의 특징

: 외부요인으로 중간에 리소스가 변경 되는 것 까지는 고려하지 않는다. 

  ex) GET, GET 사이에 다른사용자가 PUT으로 데이터를 바꿨을 때 두 번 째 GET은 같지 않다.

   - 동일한 사용자가 똑같은 요청을 여러 번 한 것에 대해서 고려한다.

 

# 캐시 가능

    - 캐시 : 로컬 PC의 웹브라우저가 내부에 데이터를 임시로 저장

 

   - 캐시를 하려면 똑같은 리소스와 키가 맞아야 되는데 POST의 경우 body안의 message 고려하면 쉽지 않음

   - GET, HEAD는 URL만 키로 잡고 캐싱하면 되서 간단하다. 실무에서는 GET만 사용

 

 

 

 

 

 

 

 

 

 

출처 : 인프런 김영한님의 강의를 수강 후 정리한 내용입니다.

 

 

 

 

꾸준히 다시보자.

 

1. 220630

2. 220714

3. 220819