[inflearn] 모든 개발자를 위한 HTTP 웹 기본 지식 (3)

HTTP 메서드

- API URI(Uniform Resource Indentifier) 고민

리소스의 의미를 담아서 설계해야 함. 

리소스 식별하는 것이 중요 : 리소스와 해당 리소스를 대상으로 하는 행위를 분리

-> 리소스는 보통 명사

ex) 회원을 등록/수정/조회/삭제 -> "회원" 개념 자체가 리소스

---

종류 - GET/POST/PUT/PATCH/DELETE

: 클라이언트와 서버 요청에 기대하는 내용.

기타

HEAD : 상태와 헤더만

OPTION : 통신 가능 옵션(CORS 같은)

CONNECT

TRACE

 

• GET : 리소스 조회, 쿼리 스트링을 통해 전달 / 메시지 바디를 사용해 데이터 전달.
• POST : 요청 데이터 처리, 메시지 바디를 통해 서버로 요청 데이터 전달 / 서버는 요청 데이터를 처리 (대상 리소스가 리소스의 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청 -> HTML 데이터 블록을 프로세스에 제공, 게시판, 뉴스 등에 메시지 게시, 서버가 아직 식별하지 않은 새 리소스 생성, 기존 자원에 데이터 추가 등..)

1.   새 리소스 등록
2.   요청 데이터 처리 (데이터 생성 변경을 넘어서 프로세스 처리) : POST의 결과로 새로운 리소스 생성이 안될 수 있음.
3.   다른 메서드로 처리하기 애매한 경우 (JSON으로 조회 데이터를 넘겨야 하는데, GET 메서드 사용 어려운 경우, 애매하면 POST)

• PUT : 리소스를 완전히 "대체" (있으면 대체, 없으면 생성 / 쉽게 말하면 덮어버림.). 클라이언트가 리소스를 식별 (클라이언트가 리소스 위치 알고 URI 지정)
• PATCH : 리소스 부분 변경 (PATCH가 지원이 되지 않는 경우에는 POST 사용)
• DELETE : 리소스 제거

 

속성

• 안전(Safe Methods)

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

 ( 해당하는 리소스만 고려. )

• 멱등(Idempotent Methods)

: 몇 번을 호출하든 결과가 똑같음.

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

• 캐시가능(Cachable)

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

GET, HEAD, POST, PATCH는 캐시 가능. (실제로는 GET, HEAD 정도만 캐시로 사용)

-> 캐시를 하기 위해서는 캐시 키를 고려해야 하기 때문에 구현이 쉽지 않음.