멱등성이란??
API 관점에서 바라보면 해당 API 에 대한 요청을 여러번 했을때 동일한 결과가 나오는것을 뜻합니다.
REST API 를 기준으로 메서드는 Get, POST, PUT, DELETE, PATCH 등 이 있습니다.
올바르게 작성이 되어있다면 GET, PUT, DELETE 와 같은 메서드는 멱등하다고 할 수 있습니다.
왜 Get, Put, Delete 는 멱등할까요?
- 리소스에 아무리 Get 요청을 하더라도 해당 리소스의 정보는 바뀌지않고 서버에도 변화가 없습니다.
- Delete 의 경우 삭제가 된 후에 동일한 삭제 요청을 보낸다면 404 Error 의 정보를 응답할 것입니다.
여기서 오해할 수 있는부분이 PATCH, POST 는 왜 멱등하지 않은데 PUT 은 멱등한가요?
라는 의문점이 들 수 있습니다.
PUT 은 해당 리소스를 완전히 대체하는 것을 만드는 것입니다. 따라서 동일한 API 를 요청하더라도 결과값이 달라지지 않습니다. 따라서 PUT 메서드는 멱등 하다고 할 수 있습니다.
POST 의 경우는 멱등성을 유지하기 위해선 추가 로직이 필요합니다.
- 왜 멱등하지 않은가?
- 게시글 작성 이라는 API 가 있다고 생각해봅시다. 이는 POST 일것이고 해당 API 를 계속 호출하게 된다면 자원은 그 상태가 유지가 될까요?? 게시글이 지속해서 생길것입니다.
그렇다면 왜 멱등성을 보장해줘야 하는걸까요?
네트워크도 정상적이고 모든 요청, 서버들이 정상적으로 작동되어 있다면 문제가 될 확률은 낮겠지만
모든 상황이 완벽하게 될 순 없겠죠? 사용자의 네트워크, 우리 서버, 서버의 네트워크 어딘가 에서 문제가 생길 수 있습니다.
따라서 Retry 와 같은 기능을 추가 할 수 있고 사용자가 여러번 누를 수 도 있겠죠
게시글의 경우 사용자가 필요없는 게시글을 삭제하면 되는일 입니다. 하지만 돈을 입금하거나 출금하는 경우 멱등성이 보장되지 않는다면 10원만 입금했는데 수십원이 입금이 되거나 취소가 되는 상황이 발생하게 됩니다. HTTP 통신을 할때 이를 방지하기 위해 사용하면 되겠습니다.
HOW?
멱등성을 보장해줘야 하는 이유를 알아봤는데 이젠 어떻게 멱등성을 보장해줄것인지를 알아봐야겠죠
방법은 심플합니다. UUID v4 와 같은 무작위적인 고유값을 헤더로 식별해주면 됩니다.
Example
추후 작성TODO
MSA 생태계는 각 서비스마다 나누어져 있기때문에 이러한 문제들이 더 자주 발생할 수 있습니다.
지금은 네트워크에서의 Issue 쪽이지만 DB의 트랜잭션을 보장하는 패턴 또한 적용해 나갈 것입니다.
프레젠테이션, 서비스, 데이터 액세스 계층에서의 데이터 동시성을 해결하고 어떻게하면 성능을 최적화 시킬수 있는지, 좋은 코드를 작성하는방법에 대해 더 공부해야겠다는 생각이 들었습니다.
Reference
