HTTP Method
HTTP API URI 설계
리소스 식별, URI 계층 구조 활용해야 한다.
회원을 조회해라. 회원을 등록해라. 회원정보를 수정해라.
위 개념에서 리소스는 “회원”이고, “조회해라, 등록해라, 수정해라”는 리소스를 대상으로 하는 행위이다. 그렇기 때문에 리소스는 명사, 행위는 동사이다.
행위(메서드)는 어떻게 구분할까? HTTP 메서드로 구분하게 된다.
✏️HTTP 메서드
GET
-
리소스 조회할 사용
-
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
-
메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많다.
POST : 요청 데이터 처리, 주로 등록에 사용
-
요청 데이터 처리
-
메시지 바디를 통해 서버로 요청 데이터 전달
-
주로 신규 데이터 등록, 변경된 프로세스를 바꿀 때 사용함.
-
새 리소스를 생성(등록)
-
요청 데이터 처리 : 단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야 하는 경우
ex) 주문 > 결제완료 > 배달시작 > 배달완료 처럼 단순히 값 변경을 넘어 프로세스의 상태가 변경되는 경우
때문에 POST 결과로 새로운 리소스가 생성되지 않을 수도 있음.
-
-
-
서버는 요청 데이터를 처리
PUT : 리소스를 대체, 해당 리소스가 없으면 생성
- 클라이언트에서 서버로 리소스를 보내는데 이 리소스로 대체할 때
ex) 파일을 폴더에 넣는데 기존의 똑같은 파일이 있으면 덮어 써버리는 개념
-
클라이언트가 리소스 위치를 정확히 알고 URI 지정, POST와의 차이점이다.
⚠️ 주의할 점은 “리소스를 완전히 대체한다”는 개념을 정확히 이해해야 한다는 것이다.
기존에 있던 리소스인 username, age와는 달리 새 리소스를 age만 보낸다면 덮어쓰기때문에 기존의 username, age 모두 사라짐.
PATCH : 리소스 부분 변경
-
리소스를 부분적으로 변경, 회원의 이름이나 특정 필드를 몇 개 바꿀 때 사용
PUT과는 달리 부분적인 변경이 가능하다.
DELETE : 리소스 삭제
삭제 요청
HTTP 메서드의 속성
안전(Safe)
- 호출해도 리소스를 변경하지 않는다.
멱등(Idempotent)
- f(f(x)) = f(x)
- 한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.
- 멱등 메서드
- GET : 한 번 조회하든, 두 번 조회하든 같은 결과가 조회된다.
- PUT : 결과를 대체한다. 따라서 같은 요청을 여러 번 해도 최종 결과는 같다.
- DELETE : 결과를 삭제한다. 같은 요청을 여러 번 새도 삭제된 결과는 똑같다.
- POST : 멱등이 아니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있다.
-
멱등은 언제 쓸까?
- 자동 복구 매커니즘을 생각해보자. DELETE를 호출했는데 서버에서 응답이 없을 때, 클라이언트가 다시 자동으로 DELETE를 요청함. DELETE는 멱등하기 때문에 자동 복구 매커니즘을 사용해도 된다.
-
재요청하는 중간에 다른 곳에서 리소스를 변경해 버리면?
- 사용자1 : GET -> username : A, age:20
- 사용자2 : PUT -> username : A, age:30
- 사용자1 : GET -> username : A, age:30 ==> 사용자 2의 영향으로 바뀐 데이터 조회
멱등은 외부 요인으로 중간에 리소스가 변경되는 것 까지는 고려하지 않는다.
캐시가능(Cacheable)
-
캐시 가능한 메서드는 응답 결과를 캐시에 저장하고 나중에 동일한 요청에 대한 응답으로 사용할 수 있는 메서드이다. 주로
GET메서드가 이에 해당하며, 캐시 기능을 활용하여 성능을 향상시킬 수 있음. -
응답 결과 리소스를 캐시해서 사용해도 될까?
- 웹 브라우저에 요청했던 이미지를 다시 요청할 필요 없이 웹브라우저 내부에 저장이 됨. (이걸 캐시라 함) ==> GET, HEAD, POST, PATCH 캐시 가능하지만 실제로는 GET, HEAD 정도만 캐시로 사용한다. GET은 url만 키로 잡고 캐시를 하면 되는데 POST, PATCH는 본문 내용까지 캐시 키로 고려해야 해 구현이 쉽지 않다.