HTTP 멱 등 성

다음으로 이동:http://www.cnblogs.com/weidagang2046/archive/2011/06/04/idempotence.html
Todd.log - a place to keep my thoughts on programming
HTTP 멱 등 성 이해
HTTP 프로 토 콜 을 기반 으로 한 웹 API 는 현재 가장 유행 하 는 분포 식 서비스 제공 방식 이다.대형 인터넷 애플 리 케 이 션 이 든 기업 급 구조 든 우 리 는 점점 더 많은 SOA 나 RESTful 의 웹 API 를 만 났 다.왜 웹 API 가 이렇게 유행 합 니까?간단 하고 효과 적 인 HTTP 프로 토 콜 덕분 이 라 고 생각 합 니 다.HTTP 프로 토 콜 은 분포 식 자원 을 대상 으로 하 는 네트워크 응용 층 프로 토 콜 로 서버 에서 웹 서 비 스 를 제공 하 든 클 라 이언 트 가 웹 서 비 스 를 소비 하 든 매우 간단 하 다.게다가 브 라 우 저,자 바스 크 립 트,AJAX,JSON,HTML 5 등 기술 과 도구 의 발전 으로 인터넷 응용 구조 디자인 은 전통 적 인 PHP,JSP,ASP.NET 등 서버 측 동적 웹 페이지 에서 웹 API+RIA(부 인터넷 응용)로 과도 하 는 추 세 를 보 였 다.웹 API 는 업무 서 비 스 를 제공 하 는 데 전념 하고 RIA 는 사용자 인터페이스 와 상호작용 디자인 에 전념 하여 이 두 분야 의 분업 이 더욱 명확 해 졌 다.이런 추세 에서 웹 API 디자인 은 서버 엔 드 프로그래머 의 필수 과목 이 될 것 이다.그러나 간단 한 자바 언어 가 고 품질의 자바 프로그램 을 의미 하지 않 는 것 처럼 간단 한 HTTP 프로 토 콜 도 고 품질의 웹 API 를 의미 하지 않 는 다.고 품질의 웹 API 를 설계 하려 면 분포 식 시스템 과 HTTP 프로 토 콜 의 특성 을 깊이 이해 해 야 한다.
멱 등 성 정의
본 고 에서 연구 하고 자 하 는 것 은 바로 HTTP 프로 토 콜 이 관련 된 중요 한 성질 인 멱 등 성(Idempotence)이다.HTTP/1.1 규범 에서 멱 등의 정 의 는:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.
정의 상 HTTP 방법의 멱 등 성 은 한 번 과 여러 번 어떤 자원 을 요청 할 때 같은 부작용 을 가 져 야 한 다 는 것 을 말한다.幂 등 성 은 어의의 범주 에 속한다.컴 파 일 러 가 문법 오 류 를 검사 하 는 데 만 도움 을 줄 수 있 듯 이 HTTP 규범 도 메시지 형식 등 문법 수단 을 통 해 그것 을 정의 할 수 없다.이것 은 이것 이 그다지 중시 되 지 않 는 원인 중 하나 일 수 있다.그러나 실제 적 으로 멱 등 성 은 분포 식 시스템 디자인 에서 매우 중요 한 개념 이 고 HTTP 의 분포 식 본질 도 HTTP 에서 중요 한 위 치 를 결정 한다.
분산 트 랜 잭 션 vs 미터 등 디자인
왜 멱 등 성 이 필요 합 니까?우 리 는 먼저 하나의 예 에서 말 하면 계좌 에서 돈 을 찾 는 원 격 API(HTTP 일 수도 있 고 아 닐 수도 있다)가 있다 고 가정 합 니 다.우 리 는 잠시 클래스 함수 로 기록 합 니 다.

bool withdraw(account_id, amount)

withdraw 의 의 미 는 accountid 에 대응 하 는 계좌 에서 amount 금액 의 돈 을 공제 합 니 다.공제 에 성공 하면 true 로 돌아 가 계 정 잔액 이 amount 감소 합 니 다.공제 에 실패 하면 false 로 돌아 가 계 정 잔액 은 변 하지 않 습 니 다.주의해 야 할 것 은 현지 환경 에 비해 우 리 는 분포 식 환경의 신뢰성 을 쉽게 가설 할 수 없다 는 것 이다.전형 적 인 상황 은 withdraw 요청 이 서버 측 에 의 해 정확하게 처리 되 었 으 나 서버 측의 반환 결 과 는 네트워크 등 으로 인해 잃 어 버 려 서 클 라 이언 트 가 처리 결 과 를 알 수 없 게 되 었 다 는 것 이다.만약 에 홈 페이지 에 있 으 면 일부 부적 절 한 디자인 은 사용자 로 하여 금 지난번 조작 이 실패했다 고 생각 하 게 하고 페이지 를 새로 고침 하 게 할 수 있 습 니 다.이 로 인해 withdraw 는 두 번 호출 되 었 고 계 정 도 한 번 더 공제 되 었 습 니 다.그림 1 참조:

그림 1
이 문제 의 해결 방안 은 분포 식 사 무 를 이용 하여 분포 식 사 무 를 지원 하 는 중간 부품 을 도입 하여 withdraw 기능 의 사무 성 을 확보 하 는 것 이다.분산 식 업무 의 장점 은 호출 자 에 게 간단 하고 복잡성 은 모두 미들웨어 에 맡 겨 관리 하 는 것 이다.단점 은 한편 으로 는 구조 가 너무 중량급 이 고 특정한 중간 부품 에 묶 이기 쉬 우 며 이 구조 시스템 의 집적 에 불리 하 다 는 것 이다.다른 한편,분포 식 사 무 는 업무 의 ACID 성질 을 보장 할 수 있 지만 성능 과 가용성 을 보장 할 수 없다.
또 다른 경량급 의 해결 방안 은 멱 등 설계 이다.우 리 는 몇 가지 기 교 를 통 해 withdraw 를 멱 등 으로 바 꿀 수 있다.예 를 들 어:

int create_ticket() 
bool idempotent_withdraw(ticket_id, account_id, amount)

create_ticket 의 의 미 는 서버 에서 생 성 된 유일한 처리 번 호 를 가 져 오 는 ticketid,이것 은 표지 의 후속 작업 에 사 용 될 것 입 니 다.idempotent_withdraw 와 withdraw 의 차 이 는 하나의 ticket 과 연 결 된 것 입 니 다.id,하나의 ticketid 가 표시 하 는 동작 은 기껏해야 한 번 만 처리 되 고 매번 호출 할 때마다 첫 번 째 호출 시의 처리 결 과 를 되 돌려 줍 니 다.이렇게,idempotentwithdraw 는 멱 등에 부합 되 므 로 클 라 이언 트 는 안심 하고 여러 번 호출 할 수 있 습 니 다.
멱 등 성 을 바탕 으로 하 는 해결 방안 중 하나의 완전한 인출 절 차 는 두 단계 로 분해 되 었 다.1.create 호출ticket()티켓 획득id；2.idempotent 호출withdraw(ticket_id, account_id, amount)。비록 createticket 은 미터 가 아 닙 니 다.그러나 이러한 디자인 에서 시스템 상태 에 미 치 는 영향 은 무시 할 수 있 습 니 다.게다가 idempotentwithdraw 는 멱 등 이기 때문에 네트워크 등 으로 인해 실패 하거나 시간 을 초과 하면 클 라 이언 트 는 결 과 를 얻 을 때 까지 다시 시도 할 수 있 습 니 다.그림 2 참조:

그림 2
분포 식 사무 에 비해 멱 등 디자인 의 장점 은 경량급 으로 이 구조 환경 에 쉽게 적응 하고 성능 과 가용성 에 있다.어떤 성능 은 비교적 높 은 응용 을 요구 하 는데,멱 등 디자인 은 왕왕 유일한 선택 이다.
HTTP 의 멱 등 성
HTTP 프로 토 콜 자 체 는 자원 을 대상 으로 하 는 응용 층 프로 토 콜 이지 만 HTTP 프로 토 콜 의 사용 에 대해 실제 적 으로 두 가지 다른 방식 이 존재 한다.하 나 는 RESTful 이 고 HTTP 를 응용 층 프로 토 콜 로 생각 하 며 HTTP 프로 토 콜 의 각종 규정 을 비교적 충 실 히 지 켰 다.다른 하 나 는 SOA 의 것 으로 HTTP 를 응용 층 프로 토 콜 로 완전히 생각 하지 않 고 HTTP 프로 토 콜 을 전송 층 프로 토 콜 로 한 다음 에 HTTP 위 에 자신의 응용 층 프로 토 콜 을 만 들 었 다.본 고 에서 논의 한 HTTP 멱 등 성 은 주로 RESTful 스타일 을 대상 으로 하지만 지난 절 에서 보 듯 이 멱 등 성 은 특정한 협의 에 속 하지 않 고 분포 식 시스템 의 특성 이다.따라서 SOA 든 RESTful 이 든 웹 API 디자인 은 멱 등 성 을 고려 해 야 한다.다음은 HTTP GET,DELETE,PUT,POST 네 가지 주요 방법의 의미 와 멱 등 성 을 소개 한다.
HTTP GET 방법 은 자원 을 얻 는 데 사용 되 며 부작용 이 없 기 때문에 멱 등 입 니 다.GEThttp://www.bank.com/account/123456자원 의 상 태 를 바 꾸 지 않 습 니 다.한 번 호출 하 든 N 번 호출 하 든 부작용 이 없습니다.여기 서 강조 하 는 것 은 매번 GET 의 결과 가 동일 한 것 이 아니 라 한 번 과 N 번 이 같은 부작용 을 가 진 다 는 점 이다.GET http://www.news.com/latest-news이 HTTP 요청 은 매번 다른 결 과 를 얻 을 수 있 지만,그 자체 가 부작용 을 일 으 키 지 않 아 멱 등 을 만족 시 킬 수 있 습 니 다.
HTTP DELETE 방법 은 자원 을 삭제 하 는 데 사용 되 며 부작용 이 있 지만 멱 등 성 을 만족 시 켜 야 합 니 다.DELETEhttp://www.forum.com/article/4231한 번 호출 과 N 번 호출 이 시스템 에 미 치 는 부작용 은 같 습 니 다.즉,id 가 4231 인 게시 물 을 삭제 하 는 것 입 니 다.따라서 호출 자 는 오 류 를 걱정 하지 않 고 페이지 를 여러 번 호출 하거나 새로 고 칠 수 있다.
헷 갈 리 기 쉬 운 것 은 HTTP POST 와 PUT 다.POST 와 PUT 의 차 이 는'POST 는 자원 을 만 드 는 것 을 나타 내 고 PUT 는 자원 을 업데이트 하 는 것 을 나타 낸다'고 간단하게 오인 되 기 쉽다.실제로 이들 은 모두 자원 을 만 드 는 데 사용 할 수 있 고 더욱 본질 적 인 차 이 는 멱 등 성에 있다.HTTP 규범 에서 POST 와 PUT 에 대해 다음 과 같이 정의 합 니 다.
The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line ...... If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.
POST 에 대응 하 는 URI 는 생 성 된 자원 자체 가 아니 라 자원 의 수신 자 입 니 다.POSThttp://www.forum.com/articles네,맛 없어 요.http://www.forum.com/articles다음 게시 물 을 만 듭 니 다.HTTP 응답 에는 게시 물의 생 성 상태 와 게시 물의 URI 가 포함 되 어야 합 니 다.두 번 의 같은 POST 요청 은 서버 에 두 개의 자원 을 만 들 것 입 니 다.서로 다른 URI 를 가지 고 있 습 니 다.그래서 POST 방법 은 멱 등 성 을 갖 추 지 못 한다.PUT 에 대응 하 는 URI 는 자원 자 체 를 만 들 거나 업데이트 하 는 것 입 니 다.PUThttp://www.forum/articles/4231ID 가 4231 인 게시 물 을 만 들 거나 업데이트 하 는 것 을 의미 합 니 다.같은 URI 에 여러 번 PUT 를 하 는 부작용 은 한 번 PUT 와 같다.따라서 PUT 방법 은 멱 등 성 을 가지 고 있다.
몇 가지 조작의 의미 와 멱 등 성 을 소개 한 후에 웹 API 형식 을 통 해 앞에서 언급 한 인출 기능 을 어떻게 실현 하 는 지 살 펴 보 자.간단 합 니 다.POST/tickets 로 create 를 실현 합 니 다.ticket；PUT/acounts/acount 로id/ticket_id&amount=xxx 로 idempotent 실현withdraw。주의해 야 할 것 은 엄 밀 히 말 하면 amount 매개 변 수 는 URI 의 일부분 이 되 어 서 는 안 되 고 진정한 URI 는/acounts/acountid/ticket_id,amount 는 요청 한 body 에 넣 어야 합 니 다.이런 모델 은 많은 장소 에 응용 할 수 있다.예 를 들 어 포럼 사이트 에서 의외 의 중복 게시 물 을 방지 할 수 있다.
총결산
위 에 서 는 분포 식 사 무 를 멱 등 으로 대체 하 는 방법 과 HTTP 주요 방법의 의미 와 멱 등 특징 을 간단하게 소개 했다.사실 근원 을 추적 하려 면 멱 등 성 은 수학의 한 개념 으로 N 차 변환 이 1 차 변환 과 같은 결 과 를 나타 내 며 관심 있 는 독자 들 은 위 키 백과 에서 더 알 수 있다.
레 퍼 런 스
RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, Method DefinitionsThe Importance of IdempotenceStackoverflow - PUT vs POST in REST