Java Reference
In-Depth Information
represents the object. For example, let's say we wanted to change the price of a product from
$199.99 to $149.99. Here's what the request would look like:
PUT
/
orders
/
233
HTTP
/
1.1
Content
-
Type:
application
/
xml
<
product id
=
"111"
>
<
name
>
iPhone
</
name
>
<
cost
>
$149
.
99
</
cost
>
</
product
>
As I stated earlier in this chapter, PUT is great because it is idempotent. No matter how many
times we transmit this PUT request, the underlying
Product
will still have the same final
state.
When a resource is updated with PUT, the HTTP specification requires that you send a re-
sponse code of 200, “OK,” and a response message body or a response code of 204, “No
Content,” without any response body. In our system, we will send a status of 204 and no re-
sponse message.
NOTE
We could use POST to update an individual
Order
, but then the client would have to assume the up-
date was nonidempotent and we would have to take duplicate message processing into account.
Removing an Order, Customer, or Product
We will model deleting an
Order
,
Customer
, or
Product
using the HTTP DELETE method.
The client simply invokes the DELETE method on the exact URI that represents the object
we want to remove. Removing an object will wipe its existence from the system.
When a resource is removed with DELETE, the HTTP specification requires that you send a
response code of 200, “OK,” and a response message body or a response code of 204, “No
Content,” without any response body. In our application, we will send a status of 204 and no
response message.
Cancelling an Order
So far, the operations of our object model have fit quite nicely into corresponding HTTP
methods. We're using GET for reading, PUT for updating, POST for creating, and DELETE
for removing. We do have an operation in our object model that doesn't fit so nicely. In our
system,
Orders
can be cancelled as well as removed. While removing an object wipes it
