🧱HTTP API 설계
URI는 리소스만 식별
리소스와 해당 리소스를 대상으로 하는 행위를 분리
- 리소스 : 회원
- 행위 : 조회/등록/삭제/변경
리소스는 명사, 행위는 동사
행위는 HTTP 메서드를 통해서 구분
📒HTTP 메서드 - GET, POST
-
✔️주요 메서드
- GET : 리소스 조회
- POST : 요청 데이터 처리, 주로 등록에 사용
- PUT : 리소스를 대체, 해당 리소스가 없다면 생성
- PATCH : 리소스 부분 변경
- DELETE : 리소스 삭제
-
✔️기타 메서드
- HEAD : GET과 동일하지만 메시지 부분을 제외하고 상태 줄과 헤더만 반환
- OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
- CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
- TRACE : 대상 리소스에 대한 경로를 따라 루프백 테스트를 수행
-
✔️GET
- 리소스 조회
- 서버에 전달하고 싶은 데이터는 쿼리 파라미터를 통해서 전달
- 메시지 바디를 사용해서 데이터를 전달할 수 있지만 지원하지 않는 곳이 많아 권장되지 않음
-
✔️POST
- 요청 데이터 처리
- 메시지 바디를 통해 서버로 요청 데이터 전달
- 서버로 요청 데이터를 처리
- 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
- 주로 전달된 데이터로 신규 리소스를 등록, 프로세스 처리에 사용
- POST 메서드는 대상 리소스가 고유한 의미 체계에 따라 요청에 포함된 표현을 처리하도록 요청한다.
📗HTTP 메서드 - PUT, PATCH, DELETE
- ✔️PUT
- 리소스를 대체
- 리소스가 있으면 이를 완전히 대체 → 부분적으로 변경하고자 할 때 사용하면 안 됨
- 리소스가 없으면 생성
- 덮는 개념
- 클라이언트가 리소스를 식별
- 클라이언트가 리소스 위치를 알고 URI를 지정하는 것
- POST와 차이점 ↔ PUT의 경우 클라이언트가 리소스의 전체 위치를 알고 URL을 지정
-
✔️PATCH
- 리소스를 부분 변경
- 리소스를 부분 변경
-
✔️DELETE
- 리소스 삭제
📘HTTP 메서드의 속성
- 안전(Safe Methods)
- 멱등(Idempotent Methods)
- 캐시 가능(Cacheable Methods)
✔️안전
- 안전이란, 호출해도 리소스를 변경하지 않는다는 의미이다.
- 계속 호출해서 로그가 쌓여 장애가 발생하더라도 안전은 그런 부분까지 고려하지 않는다. 해당 리소스만을 고려한다.
- GET의 경우 리소스를 조회만 하기 때문에 리소스의 변경이 일어나지 않는다. 따라서 안전하다고 할 수 있다.
- 반면 POST의 경우 리소스를 생성하기 때문에 리소스의 변경이 일어난다. 따라서 안전다고 할 수 없다. DELETE, PUT, PATCH 전부 다 안전하지 않은 것이다.
✔️멱등
f(f(x)) = f(x) // 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
- GET : 한 번 조회하든 두 번 조회하든 같은 결과가 조회된다.
- PUT : 결과를 대체한다. 처음엔 바뀌겠지만 그 이후부터는 같은 요청을 여러번 해도 최종 결과는 같다.
- DELETE : 결과를 삭제한다. 역시 처음엔 바뀌겠지만 그 이후부터는 같은 요청을 여러번 해도 삭제된 최종 결과는 같다.
- POST : 멱등이 아니다. 두 번 호출하면 중복해서 발생할 수 있다.
Ex1. 사용자1의 GET 요청 → username:A, age:20
Ex2. 사용자2의 PUT 요청 → username:A, age:30
Ex3. 사용자1의 GET 요청 → username:A, age:30 → 사용자2의 영향으로 바뀐 데이터를 조회
※ 멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.
✔️캐시 가능
- 응답 결과 리소스를 캐시해서 사용해도 되는가?
- GET, HEAD, POST, PATCH 캐시 가능
- 실제로는 GET, HEAD 정도만 캐시로 사용
- POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하는데 구현이 쉽지 않음
