HTTP API
- API URI를 만들 때 가장 중요한 것은 리소스 식별
- 리소스: 회원
- 리소스와 해당 리소스를 대상으로 하는 행위을 분리
- 행위: 조회, 등록, 삭제, 변경
- 예시=>
- GET 회원 목록 조회 /members
- GET 회원 조회 /members/{id}
- POST 회원 등록 /members/{id}
- PATCH 회원 수정 /members/{id}
- DELETE 회원 삭제 /members/{id}
HTTP 메서드 종류 주요 메서드
- GET: 리소스 조회
- POST: 요청 데이터 처리, 주로 등록에 사용
- PUT: 리소스를 대체, 해당 리소스가 없으면 생성
- PATCH: 리소스 부분 변경
- DELETE: 리소스 삭제
HTTP 메서드 종류 기타 메서드
- HEAD: GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
- OPTIONS: 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명(주로 CORS에서 사용)
- CONNECT: 대상 리소스로 식별되는 서버에 대한 터널을 설정
- TRACE: 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행
HTTP 메서드의 속성
- 안전 (Safe Methods)
- 멱등 (Idempotent Methods)
- 캐시가능 (Cacheable Methods)
안전 (Safe Methods)
- 호출해도 리소스를 변경하지 않는다.
- ex) GET 요청 한다고 리소스 변경되지 않음
- Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면?
- A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다.
멱등 (Idempotent Methods)
- 멱등: 여러번 호출하든 결과가 항상 같은 경우 f(f(x)) = f(x)
- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
- 위에서 언급한 네 메서드 중에, POST만 멱등하지 않음!! (ex. 중복결제)
- GET: 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
- PUT: 결과를 대체한다. 따라서 같은 요청을 여러번 해도 최종 결과는 같다.
- DELETE: 결과를 삭제한다. 같은 요청을 여러번 해도 삭제된 결과는 똑같다.
- POST: 멱등이 아니다! 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
- 필요성: 자동 복구 메커니즘
- ex) 서버가 timeout 등으로 정상 응답 못할 때, 클라이언트가 다시 요청해도 되는가? 판단 근거
- 마찬가지로 외부 요인으로 리소스 변경되는 것 까지는 고려 x
캐시가능 (Cacheable Methods)
- 응답 결과 리소스를 캐시해서 사용해도 되는지?
- GET, HEAD, POST, PATCH 캐시 가능
- 하지만 실제로는 GET, HEAD 정도만 캐시로 사용함. (POST, PATCH는 캐시 키 고려해야하는데 구현 쉽지 않음)
출처 : 모든 개발자를 위한 HTTP 웹 기본 지식
