| > The possible creation of extra HTTP resources (response resorces?) seems to me contrary to idempotency. A GET request might create additional (or modify existing) resources, say if the API exposed it's own log via HTTP. Both safe and idempotent are less expensive than one might naively think in the HTTP spec (which is good, because the naive understanding, while aesthetically seductive, isn't very practical at all.)
Some quotes from the relevant bits of RFC 7231: “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.” “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.” “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.” |