rfc7231 - 4.2 Common Method Properties (일부-멱등성)

단지 RFC 문서를 구글 번역기를 돌린 내용 입니다.

4.2.1.  Safe Methods

Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource.  Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.

정의된 의미 체계가 본질적으로 읽기 전용인 경우 요청 메서드는 "안전한" 것으로 간주됩니다. 즉, 클라이언트는 대상 리소스에 안전한 방법을 적용한 결과 원본 서버의 상태 변경을 요청하지 않으며 예상하지도 않습니다. 마찬가지로 안전한 방법을 합리적으로 사용한다고 해서 원본 서버에 피해, 재산 손실 또는 비정상적인 부담이 발생하지 않을 것으로 예상됩니다.

This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method.  What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it.  For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and crash the server.  Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.

이 안전한 메서드 정의는 잠재적으로 유해하거나 완전히 읽기 전용이 아니거나 안전한 메서드를 호출하는 동안 부작용을 일으키는 동작을 구현에 포함하는 것을 방지하지 않습니다. 그러나 중요한 것은 내담자가 추가 행동을 요청하지 않았으며 이에 대해 책임을 질 수 없다는 것입니다. 예를 들어, 대부분의 서버는 방법에 관계없이 모든 응답이 완료될 때 로그 파일에 액세스하기 위해 요청 정보를 추가하며, 이는 로그 저장소가 가득 차서 서버가 충돌할 수 있는 경우에도 안전한 것으로 간주됩니다. 마찬가지로 웹에서 광고를 선택하여 시작된 안전한 요청은 종종 광고 계정에 비용을 청구하는 부작용이 있습니다.

Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.

본 명세서에서 정의한 요청 메소드 중 GET, HEAD, OPTIONS, TRACE 메소드는 안전한 것으로 정의되어 있다.

The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm.  In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.

안전한 방법과 안전하지 않은 방법을 구분하는 목적은 자동화된 검색 프로세스(스파이더)와 캐시 성능 최적화(프리페칭)가 피해를 입을 염려 없이 작동하도록 하는 것입니다. 또한 사용자 에이전트가 잠재적으로 신뢰할 수 없는 콘텐츠를 처리할 때 안전하지 않은 방법의 자동화된 사용에 적절한 제약 조건을 적용할 수 있습니다.

A user agent SHOULD distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware of an unsafe action before it is requested.

사용자 에이전트는 사용자에게 잠재적인 작업을 제시할 때 안전한 방법과 안전하지 않은 방법을 구별하여 요청하기 전에 사용자가 안전하지 않은 작업을 알 수 있도록 해야 합니다(SHOULD).

When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action, it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics.  For example, it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete".  If the purpose of such a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method.  Failure to do so will result in unfortunate side effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, building a search index, etc.

효과적인 요청 URI 내의 매개변수가 작업을 선택하는 효과가 있도록 리소스가 구성될 때 작업이 요청 메서드 의미 체계와 일치하는지 확인하는 것은 리소스 소유자의 책임입니다. 예를 들어, 웹 기반 콘텐츠 편집 소프트웨어는 "page?do=delete"와 같은 쿼리 매개변수 내에서 작업을 사용하는 것이 일반적입니다. 그러한 리소스의 목적이 안전하지 않은 작업을 수행하는 것이라면 리소스 소유자는 안전한 요청 방법을 사용하여 액세스할 때 해당 작업을 비활성화하거나 허용하지 않아야 합니다. 그렇게 하지 않으면 자동화된 프로세스가 링크 유지 관리, 프리페칭, 검색 인덱스 구축 등을 위해 모든 URI 참조에 대해 GET을 수행할 때 불행한 부작용이 발생합니다.

4.2.2.  Idempotent Methods

A request method is considered "idempotent" if the intended effect on   the server of multiple identical requests with that method is the same as the effect for a single such request.  Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.

요청 방법을 사용하여 여러 개의 동일한 요청이 서버에 미치는 영향이 단일 요청에 대한 효과와 동일한 경우 요청 방법은 "멱등원"으로 간주됩니다. 이 사양에서 정의한 요청 방법 중 PUT, DELETE 및 안전한 요청 방법은 멱등원입니다.

Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.

안전의 정의와 마찬가지로 멱등 속성은 사용자가 요청한 경우에만 적용됩니다. 서버는 각 요청을 개별적으로 기록하거나, 개정 제어 기록을 유지하거나, 각 멱등 요청에 대해 다른 비멱등 부작용을 구현할 수 있습니다.

Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response.  For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request.  It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.

멱등 메서드는 클라이언트가 서버의 응답을 읽을 수 있기 전에 통신 장애가 발생하면 자동으로 요청을 반복할 수 있기 때문에 구별됩니다. 예를 들어 클라이언트가 PUT 요청을 보내고 응답이 수신되기 전에 기본 연결이 닫히면 클라이언트는 새 연결을 설정하고 멱등 요청을 다시 시도할 수 있습니다. 요청을 반복하면 원래 요청이 성공하더라도 응답은 다를 수 있지만 의도한 것과 동일한 효과가 있음을 알고 있습니다.