Idempotent methods may change resource state, but they are not
required to (all safe methods are by definition idempotent).
The result of this definition is resiliency; if a client initiates a PUT request and is not
sure whether it completed successfully, it can retry the same request with no negative
consequences.
190 | Chapter 7: REST, Resources, and Web Services
DELETE
As its name implies, the DELETE method deletes the resource identified by its URI. If
the deletion is carried out (the server may not allow a deletion), subsequent GET queries
to the same URI should return a status code of 410 (Gone) or 404 (Not Found).
POST
We list POST last because it is the method of last resort. It is neither safe nor idempotent,
so there are few technical restrictions to its power. As such, it is abused for
many operations that could better be represented by another verb. Theoretically,
POST could be used for every action on the Web without violating the letter of the
RFC.
Though POST is powerful, it should not be used where GET, PUT, or DELETE would suffice.
The semantics of those three methods are much simpler, and the constraints put
on them allow easier caching and scalability. POST can, in theory, be cached via the
Cache-Control and Expires headers, but in practice this is rarely implemented.
POST is primarily used in one of two ways: creation of new objects and annotation of
existing objects.
Pages:
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297