HTTP / HTTP 메서드

API URI(Uniform Resource Identifier) 설계

회원이라는 리소스만 식별

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

 

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

>> 리소스 : 회원

>> 행위 : 조회, 등록, 삭제, 변경

 

HTTP 메서드 종류

GET : 리소스 조회

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

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

PATCH : 리소스 부분 변경

DELETE : 리소스 삭제

 

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

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

CONNECT : 대상 리소스로 식별되는 서버에 대한 터널 설정

TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트 수행

 

GET

리소스 조회

 

서버에 전달하고 싶은 데이터

>> query를 통해 전달

메시지 바디 사용 가능, but 권장 x

 

POST

요청 데이터 처리

 

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

서버는 요청 데이터를 처리

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

 

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

 

PUT

리소스를 완전 대체

>> 있으면 대체, 없으면 생성

 

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

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

>> POST와 차이점

 

PATCH

리소스 부분 변경

 

DELETE

리소스 제거

 

HTTP 메서드의 속성

안전(Safe)

호출해도 리소스 변경 x

 

멱등(Idempotent)

한번 호출하든 100번 호출하든 결과가 같음

 

멱등 메서드 : GET, PUT, DELETE

비멱등 메서드 : POST (같은 결제가 중복 발생 가능)

 

자동 복구 메커니즘

서버가 TIMEOUT 등으로 정상 응답을 못주었을 때

>> 클라이언트가 같은 요청을 다시 해도 되는가? 판단 근거

 

멱등은 외부 요인으로 중간에 리소스가 변경되는 것까지는 고려 x

 

캐시가능(Cacheable)

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

 

캐시가능 : GET, HEAD, POST, PATCH

>> 실제로는 GET, HEAD 정도만 사용

>> POST, PATCH는 구현 어려움