RESTful web services - Making Java Groovy - page 304

(whose first name is the definitive functional programming language, and whose last name is a fundamental coding
technique; if your name is your resume, you win).
In his thesis, Fielding defines the REST architecture in terms of addressable resources and
their interactions. When restricted to HTTP requests made over the web (not a requirement
of the architecture, but its most common use today), RESTful web services are based on
the following principles:
• Addressable resource— Items are accessible to clients through URIs.
• Uniform interface— Resources are accessed and modified using the standard
HTTP verbs GET, POST, PUT, and DELETE. [ 3 ]
3 Some services support HEAD requests as GET requests that return headers with empty responses and
OPTIONS requests as an alternate way to specify what types of requests are valid at a particular address.
PATCH requests are proposed as a way to do a partial update.
• Content negotiation— The client can request different representations of re-
sources, usually by specifying the desired MIME type in the Accept header of a
request.
• Stateless services— Interactions with resources are done through self-contained
requests.
Web services based on these ideas are intended to be highly scalable and extensible, be-
cause they follow the mechanisms that make the web itself highly scalable and extensible.
Part of the scalability of a RESTful web service comes from the terms safe and idempotent :
• Safe— Does not modify the state of the server
• Idempotent— Can be repeated without causing any additional effects
GET requests are both safe and idempotent. PUT and DELETE requests are idempotent
but not safe. They can be repeated (for example, if there's a network error) without making
any additional changes. [ 4 ] POST requests are neither safe nor idempotent.
4 Sometimes it's hard to picture DELETE requests as idempotent, but if you delete the same row multiple times, it's
still gone.