HTTP 메서드

API URI 설계

리소스 식별, 계층 구조로

 

리소스와 행위( 해당 리소스를 대상으로 하는 )를 분리

• 리소스: 회원
• 행위: 조회, 등록, 삭제, 변경

 

HTTP 메서드

클라이언트가 서버에게 요청할때 기대하는 행동

주요 메서드
GET	서버에게 리소스 달라고 요청
POST	데이터 줄테니까 처리( 주로 등록 )해 달라
PUT	서버로 리소스를 보내는데 이 리소스로 대체해줘, 해당 리소스가 없으면 생성 ( 파일을 폴더에 넣을때, 없으면 폴더에 파일이 새로 생기고 기존에 파일이 있으면 덮어버림 )
PATCH	리소스를 부분 변경  ( 회원의 이름을 바꾸거나 특정 필드를 몇개 바꾸는거 )
DELETE	리소스 삭제

 

GET

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

 

POST

• 메시지 바디를 통해 서버로 데이터 전달, 서버는 데이터를 받아서 처리

 

• 다른 메서드로 처리하기 애매한 경우 POST사용

예) JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드를 사용하기 어려운 경우

 

참고) GET method에서 메시지바디는 서버들이 처리를 안하는경우가 많음

조회할땐 GET을 쓰는게 유리( GET으로 오면 캐싱을 함, POST로 오면 캐싱 하기 어려움 )

• 이런식으로 URI 를 설계하기도 POST /orders/{orderId}/start-delivery

 

PUT

• 리소스를 그냥 박아버림( 없으면 생성 )

• 클라이언트가 리소스 위치를 알고 URI 지정( 클라이언트가 리소스를 식별 , POST와 차이점 )

예) POST에선 /members , PUT에선 /members/100

 

PATCH

•  PUT은 통째로 바뀌지만, PATCH는 리소스 부분변경

•  PATCH가 지원 안되는 서버들도 있음, 그럴경우는 POST 쓰면 됨

 

DELETE

리소스 제거( 해당 리소스 제거됨 )

 

HTTP 메서드의 속성

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

안전( Safe )

• 호출해도 리소스가 변경이 않된다.
• GET만 해당( 각각 http메서드 의미 떠올려보면 알수 있음 )

멱등( Idempotent )

• f(f(x)) = f(x)  ,  한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
• POST만 아님( ex 두번 결제 )
• 자동 복구 메커니즘 으로 활용됨
예) 서버가 TIMEOUT 등으로 정상 응답을 못주었을 때( 정상 처리됐는지 알수 없을때 ), 클라이언트가 자동으로 같은 요청을 다시 하는거

캐시가능( Cacheable )

• 응답 결과를 캐시해서 사용할수 있는가
• 캐시 : 로컬pc에 웹브라우저가 저장하고 있는거, 웹브라우저가 내부에 저장하고 있는거
• 실제로는 GET, HEAD 정도만 캐시로 사용
• 캐시를 하려면 key가 맞아야함

GET은 url만 key로 잡고 캐시를 하면됨 / POST, PATCH는 본문 내용까지 key로 고려해야 하는데 쉽지 않음