도움 되었어요!

강의가 도움이 되었다니 다행입니다!공부하시다가 궁금한 점이나 더 깊이 알고 싶은 부분이 생기면 언제든 질문 남겨주세요~감사합니다!

멱등성. '같은 요청'의 기준?

안녕하세요, akakakak님.말씀해주신 것처럼, 기존 필드의 조합만으로는 동일한 요청인지 정확히 판단하기 어려운 경우가 많습니다. 그래서 API를 설계할 때 멱등성을 보장하는 대표적인 방법은 클라이언트가 요청 시 고유한 키를 함께 보내도록 하는 것입니다.이 외에도 시스템의 상태를 기반으로 멱등성 여부를 판단하거나, HTTP 메서드의 특성을 활용해 별도 처리가 필요 없는 방식도 있습니다.클라이언트가 요청에 고유한 키를 함께 보냄 (멱등성 키)예를 들어, 결제가 중복되지 않도록 하고 싶은 경우 클라이언트가 요청을 보낼 때 고유한 키(예: UUID) 를 만들어 함께 전송할 수 있습니다.서버는 이 키를 기준으로 중복 요청 여부를 판단해, 이미 처리한 요청이라면 다시 처리하지 않습니다.보통 서버는 이 키를 Redis 같은 캐시에 저장하고, 일정 시간 동안 유효하도록 설정해두는 경우가 많습니다.(이 방식은 10강 '서버와 서버 간 통신' 마지막 부분에서도 언급되니 참고해주시면 좋습니다.) 상태 기반 처리현재 시스템이 가진 데이터의 상태를 DB에서 확인해서 이를 기준으로 중복 요청 여부를 판단할 수도 있습니다.예를 들어, 주문을 '배송중'으로 업데이트하는 API에서 주문 123번이 이미 '배송중' 상태라면, 같은 상태로 변경하는 요청이 들어왔을 때 중복 요청으로 간주해 처리하지 않을 수 있습니다. 서버의 동작이 HTTP 메서드의 멱등성 의도에 맞게 구현HTTP 명세에서 PUT, DELETE, GET 등의 메서드는 같은 요청을 여러 번 보내도 같은 결과가 나와야 한다는 멱등성을 가진 요청입니다. 이 의도가 서버 API에 정확히 구현되어 있다면, 별도 처리 없이도 자연스럽게 멱등성이 보장될 수 있습니다.예를 들어, S3 같은 오브젝트 스토리지에 파일을 업로드할 때 'PUT /file1'처럼 같은 경로로 파일을 여러 번 업로드하더라도 기존 파일을 덮어쓰기 때문에 결과는 항상 같습니다.모든 API가 멱등성을 반드시 보장해야 하는 것은 아니므로,API의 역할과 도메인 특성을 고려해 필요한 경우에는 위 방법들 중 적절한 방식을 선택해 적용해줄 수 있습니다.