HTTP 메서드

API URI 고민

URI (Uniform Resource Identifier)

• 회원이라는 개념 자체가 리소스

• 회원이라는 리소스만 식별하면 된다 → 회원 리소스를 URI에 매핑

GET

리소스 조회

• 서버에 전달하고 싶은 데이터는 쿼리를 통해 전달

• 메시지 바디를 사용해서 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장 X

POST

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

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

• 서버는 요청 데이터를 처리

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

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

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

PUT

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

• 덮어쓰기

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

PATCH

리소스 부분 변경

• 부분 필드값에 대해서만 리소스의 데이터를 바꾸어준다.

DELETE

리소스 제거

기타 메서드

• HEAD

• OPTIONS

• CONNECT

• TRACE

HTTP 메서드의 속성

안전

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

멱등 Idempotent

• 한 번 호출하든 여러번 호출하든 결과가 동일하다.

• 멱등 메서드
• GET
• PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
• DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 결과는 똑같다.
• POST: 멱등이 아니다!!! 두번 호출하면 같은 결제가 중복해서 발생할 수 있다.

• 활용
• 자동 복구 메커니즘
• 서버가 TIMEOUT 등으로 정상 응답을 못주었을때, 클라이언트가 같은 요청을 다시 해도 되는가에 대한 근거

캐시 가능 Cacheable

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

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

• 실제로는 GET, HEAD 정도만 캐시로 사용
• POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데, 구현이 어렵다.