But another, more important, purpose of the HTTPspecification is to form an explicit
contract between the server, the client, and any proxies or caches along the way. This
tells each principal what they can and cannot assume about the data they work with.
The concepts of safe and idempotent methods fall under this category.
Safe methods are used for retrieval; the purpose of a safe request should never be to perform
an update. The HTTPsafe methods are GET and HEAD. (HEAD is functionally equivalent
to GET, but only returns the response headers, not the body.)
Safety is usually defined at the application level, and the definition of a safe method can
change based on application semantics. A GET operation may incur incidental side
effects, such as loading query results into a cache or updating a hit counter; the action
would still be described as safe. The distinction drawn by the HTTPspecification is
that safe requests should not incur an obligation on the user??™s behalf (such as an online
payment or creation of a user account). In other words, it must always be the server
that decides to perform an update based on a safe request.
GET, HEAD, PUT, and DELETE are idempotent methods. The result (response as well as
resource state) of an idempotent action is the same, no matter how many times that
action is performed (assuming each action is identical and there is otherwise no change
to resource state).
Pages:
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296