240106 HTTP 메서드

 

 

 

좌) 안 좋은 설계 예   우) 좋은 설계 예

리소스 식별이 중요하다

URI는 리소스 식별,  행위는 HTTP 메소드로 식별

리소스는 명사, 행위method는 동사

 

 

 

HTTP 메서드

 

 

총 10개인데 주로 4~5개만 쓴다

 

GET

-리소스 조회
-서버에 전달할 데이터는 쿼리로 전달
-메세지바디에 내용을 넣을순 있지만 그걸 지원 안하는 서버로 왕왕 있다.
 

POST

-요청 데이터 처리, 주로 등록에 사용
-☆메세지 바디를 통해 서버로 요청 데이터 전달
주 사용처
  -새 리소스 생성(가입, 글 등록, 댓글 등등)
  -요청 데이터 처리 -> 새 리소스가 생성/변경 되지 않고 프로세스를 처리해야할때
  -다른 메서드로 처리하기 애매할때 -> JSON 조회데이터를 넘겨야하나 GET 사용이 힘들때

그냥 POST는 메세지바디에 담아 보내는 모든걸 할 수 있다. 만능 메소드 짱
 

PUT

- 원 리소스를 대체, 원 리소스가 없으면 새로 생성 ->덮어쓰기 
- 일부 변경이 불가능하다. 한 컬럼만 바꾸면 나머지 컬럼은 삭제됌
- 수정보단 갈아끼우기 느낌
- POST와 달리 정확한 위치{id}를 알고 있어야함
 
PATCH

-리소스 부분 변경.
-PUT의 신버젼
-안되는 서버도 간혹 있다. 그럴땐 POST를 사용!
 

DELETE

-리소스 삭제   

 

 

 

HTTP 메서드의 속성

 

 

 

 

안전(Safe Methods)

호출해도 리소스를 변경하지 않는가?

--> GET

+'리소스 안전'에 관한것만 한정함으로 쌓인 로그로 인한 오류는 제외

 

멱등(Idempotent Methods) 덮을 멱, 등급 급

여러 번 호출하더라도 같은 결과가 나오는가?

-->GET, PUT, DELETE
POST는 멱등하지 않다 호출하는대로 데이터가 생겨나니깐

TIMEOUT 등으로 정상 응답을 받지 못했을때 다시 요청해도 되는지? 에 사용

+외부요인(PUT,PATCH)으로 리소스가 바뀐건 고려하지 않는다

 

캐시가능(Cacheable Methodsd)

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

-> GET, HEAD, POST, PATCH

POST, PATCH는 본문 내용까지 캐시 키로 고려해 구현이 어려워서 주로 GET, HEAD로 사용