요점 정리 : 금융 관련 결제 같은 요청들은 멱등성이 보장되는 메서드들 꼭꼭 사용하기
순서
- 멱등성이란?
- 멱등성이 필요한 이유
- HTTP Method의 멱등성
- 설계시 고려해야할 점
- 참고사이트
멱등성이란?
HTTP 메소드의 속성 중에 하나인 멱등성은 여러 번 동일한 요청을 보냈을 때, 서버에 미치는 의도된 영향이 동일할 경우를 말한다. 예를 들어 Safe 요청인 GET, HEAD등과 함께 PUT, DELETE를 멱등한 HTTP 메소드라고 정의한다. DELETE는 요청 한번 보냈을 때 DELETE -> 200 OK 응답 값이 오고 동일한 요청을 보낼 경우 에러 DELETE-> 404 NOT FOUND 를 받지만 멱등성의 기준은 요청 응답 기준이 아닌 서버 기준임을 명시하자. PATCH 또한 리소스를 수정할 경우 기존 리소스에 응답을 추가하는 경우에도 사용될 수 있는데 이때, 호출 결과가 달라질 수 있으므로 멱등하다 할 수 없다.
HTTP 메소드 중 멱등한 메소드
- GET, PUT, DELETE
HTTP 메소드의 멱등성이 필요한 이유는 ?
1. 안전한 요청
멱등한 메소드는 서버 상태를 변경하지 않고 리소스에 대한 정보를 요청하는 데 사용될 수 있다. 이는 해당 요청이 오류 또는 부작용을 발생시키지 않고 여러 번 호출될 수 있음을 의미한다. 예를 들어, HTTP의 GET 메소드는 멱등성을 가지고 있다.
2. 캐싱
멱등한 메소드를 사용하면 캐싱이 더욱 효과적으로 이루어질 수 있다. 동일한 요청에 대한 응답은 항상 동일하므로 캐시된 응답을 재사용할 수 있다.
3. 병행 처리와 복구
멱등한 메소드는 여러 클라이언트에서 동시에 호출되더라도 예상된 결과를 얻을 수 있습니다. 이는 분산 환경에서 병행 처리를 쉽게 만들어주며, 시스템이 실패하거나 중단되더라도 안전하게 복구할 수 있도록 한다.
4. 사용자 경험 향상
멱등한 메소드를 사용하면 사용자 경험이 향상될 수 있다. 사용자가 "새로 고침" 버튼을 누르거나 다시 시도 버튼을 클릭하여 동일한 요청을 여러 번 시도해도 예상된 동일한 결과를 받을 수 있다.
5. 네트워크 문제 대응
멱등한 메소드를 사용하면 네트워크 문제로 인해 요청이 중단되었을 때 다시 시도하는 것이 더 쉽다. 동일한 요청을 여러 번 시도해도 동일한 결과를 얻을 수 있기 때문이다.
멱등성이 필요한 예시
결제 시스템
결제 시스템에서 멱등성은 중요한 개념이다. 결제는 금전적인 거래이기 때문에 중복 결제나 잘못된 금액의 결제 등을 방지하기 위해 멱등성이 필요하다.
- 중복 결제 방지
- 사용자가 결제 버튼을 눌렀을 때, 네트워크 문제 또는 다양한 이유로 인해 응답이 늦게 도착하거나 사용자 측에서 재시도를 했을 경우 중복 결제가 발생할 수 있다. 멱등성이 없는 경우에는 동일한 결제 요청이 여러 번 발생하면 여러 번의 결제가 이루어질 수 있다. 멱등성이 있는 결제 시스템에서는 동일한 결제 요청이 여러 번 수행되어도 결제가 한 번만 이루어진다.
- 오류 복구
- 결제 시스템에서 오류가 발생했을 때, 사용자나 시스템이 다시 시도를 할 수 있다. 이때 멱등성이 있는 결제 시스템에서는 동일한 결제 요청을 여러 번 시도해도 동일한 결과를 얻을 수 있다.
- 시스템 간 통신 문제 대응
- 결제 요청은 여러 시스템 간의 통신을 포함할 수 있다. 이때 통신 문제로 인해 요청이 중단되거나 응답이 손실될 수 있다. 멱등성이 있는 결제 시스템에서는 시스템 간 통신 문제로 인한 중복 결제를 방지할 수 있다.
#결제 요청 예시
http
Copy code
POST /payments
Content-Type: application/json
{
"amount": 50.00,
"card_number": "1234-5678-9012-3456",
"expiry_date": "12/24",
"cvv": "123",
"order_id": "abc123"
}해당 결제 요청이 여러 번 수행되더라도 동일한 order_id에 대한 결제는 한 번만 이루어진다. 이는 멱등성을 통해 중복 결제를 방지하고 시스템의 안정성을 높이는 데 도움된다.
추가적인 예시
- 자동 이체나 정기 결제 서비스 같이 사용자가 한번 등록한 이체나 결제 요청이 여러번 발생 할 수 있는데, 멱등성은 이러한 상황에서 중복 이체나 결제를 방지할 수 있게 안정적인 서비스 제공에 도움을 준다.
- 만약 매월 특정 날짜에 자동이체를 등록해둘 경우, 오류로 인해 여러번 요청이 되더라도
transaction_id에 대한 이체가 한 번만 이루어지게 해둘 수 있다.
멱등성은 금융 거래와 같은 중요한 작업에서 특히 중요한 역할을 한다.
GET과 POST의 차이와 설계시 고려할 점
간단하게 차이점을 얘기하면 GET은 정보의 요청, POST는 정보의 제출로 볼 수 있다.
GET(멱등성 O)
- 주로 쿼리스트링을 통해 데이터를 전송하며 url에 데이터가 노출이 됨으로 보안에 취약할 수 있으니 민감한 정보는 담지않는 것이 좋다. 또한 데이터의 길이 제한이 있다.
- 캐싱이 가능하고, 동일한 GET 요청에 대한 응답은 캐시에서 가져와 사용할 수 있다.
POST(멱등성 X)
- 주로 리소스를 생성하거나 업데이트할 때 사용된다. 요청은 바디에 데이터를 담아 전송한다. url에 데이터가 노출되지 않으므로 GET 보다는 보안에 우수하지만 특정 경우를 제외하고는 목적을 분명하게 사용하는 편이 좋다. 데이터의 길이 제한이 없다.
- 캐싱이 어렵기 때문에, 동일한 POST 요청의 응답은 캐시에서 가져오지 않는다.
설계시 고려할 점
- 보안
- 민감한 정보를 전송해야 하는 경우 POST를 사용하는 것이 좋다.
- 데이터 길이
- 큰 데이터를 전송해야 할 경우 POST를 사용하는 것이 적절하다. GET은 URL 길이 제한이 있을 수 있다.
- 멱등성
- 멱등성이 필요한 작업인지 고려하여 적절한 메소드를 선택한다.
- 조회나 검색과 같이 멱등성이 중요한 경우 GET을 사용하고, 리소스 변경이 필요한 경우에는 POST를 사용한다.
- HTTP 메소드의 적절한 사용은 웹 애플리케이션의 안정성, 효율성, 보안성 등에 영향을 미치므로 주의 깊게 고려되어야 한다.
- 캐싱
- 캐싱이 중요한 경우 GET을 사용하여 캐싱을 활용한다.
- RESTful 설계
RESTful API를 설계할 때는 각 메소드의 의도에 맞게 사용해야 한다.
리소스의 조회는 GET, 생성은 POST와 같이 목적에 따라 메소드를 사용한다.
