REST 아키텍처를 따라 API를 개발하게 되면 아래와 같은 규칙만큼은 꼭 따르고 있을 것이다.
- URI를 통해 리소스를 식별한다.
- HTTP Method로 리소스에 수행해야 하는 작업을 서버에게 알려준다.
그래서 Method를 수행해야 할 동작에만 초점을 맞추고 사용을 해왔는데 Method들마다 속성이 있다고 하니 안정성, 멱등성, 캐시가능성에 대해 정리해보고자 한다.
해당 글에서는 가장 많이 사용되는 5가지 Method인 GET, POST, PUT, PATCH, DELETE만 가지고 작성했다.
안정성
GET
HTTP 메서드가 서버의 상태를 바꾸지 않으면 해당 메서드는 안전하다고 본다.
쉽게 얘기하면 읽기 작업을 수행하는 메서드는 안전하다고 할 수 있다. 계속해서 읽기 작업을 수행한다 해도 갑자기 해당 메서드때문에 읽던 데이터가 변형될 일이 없기 때문이다.
그래서 안전한 메서드는 멱등성 또한 가지지만, 멱등성을 가진 메서드가 모두 안전하지는 않다.
PUT이나 DELETE는 멱등성을 가지지만 요청을 보낼 때 데이터를 생성하고 삭제하기 때문!
아래의 멱등성 개념을 본다면 이해가 조금 수월할 것이다.
멱등성
GET, PUT, DELETE
동일한 요청을 한 번 보내는 것과 여러번 연속으로 보내는 것이 같은 효과를 지니고, 서버의 상태도 동일하게 남는다면 해당 HTTP 메서드는 멱등성을 가졌다고 말한다.
쉽게 같은 리소스에 대해 동일한 요청을 계속 보내도 상태가 동일하게 남냐는 말로 이해했다.
멱등성을 만족하지 않는 POST나 PATCH메서드는 같은 요청을 계속 보낸다면 새로 리소스가 생성되거나 계속 수정이 될 것이다.
하지만 GET, PUT, DELETE는 같은 데이터가 계속 조회되고, 계속 덮어쓰고, 계속 삭제된 상태가 유지되므로 멱등성을 만족한다.
예외사항
그럼 PATCH를 PUT처럼 사용하면 어떻게 될까?
그럼 멱등성을 만족한다. 여러번 요청해도 계속 같은 데이터로 남기때문에 상태가 동일하기 때문에!
그럼 GET은 항상 멱등성을 만족하나?
사실 이부분이 가장 궁금한데 멱등성을 만족하기 위해선 통계 기록을 제외하면 어떠한 side effect도 발생하면 안된다고 한다.
통계로는 로깅같은 것을 말하는 것 같은데 GET요청으로 프로필을 조회하고 조회 순위를 정하기 위해 조회수를 1 늘린다면 멱등성을 만족하는것일까
이 글에서도 토론을 하는 것 같은데 해소되지는 않았다.
주의할 점
DELETE메서드가 삭제에 성공하고 200상태코드를 반환한 이후에 다시 요청하면 찾을 수 없으니 404코드를 반환한다고 해보자.
상태코드가 달라졌으니 멱등성을 만족하지 않는것일까? 아니다. 멱등성을 따질 때는 서버의 응답 코드보다는 서버의 상태만 보면 된다고 한다.
따라서 DELETE도 항상 목록의 마지막 항목을 제거하도록 API를 설계했다면 해당 API는 멱등성을 만족하지 않게 된다.
요청을 할 때마다 마지막 자원이 삭제 되기에...
캐시가능성
GET
요청 이후 응답을 재사용하기 위해 캐싱할 수 있는 것을 의미한다.
GET Method가 가능하다고 하며 POST, PATCH는 캐시될 수 있지만 지원이 거의 되지 않는다고 한다.
마치면서
가장 주의해야 할 메서드는 멱등성을 만족하지 않는 POST, PATCH라고 생각하는데 자원을 계속 생성하고 수정하기 때문에 해당 메서드로 민감한 정보를 다룬다면 실제로 요청이 갔는데 응답을 받지 못한건지 요청자체가 실패한건지를 잘 파악해야겠다.
참고
