Java Reference
In-Depth Information
one particular Order , but for now, let's assume they are hidden by the data format. Given
this, here is a list of URIs that will be exposed in our system:
/ orders
/ orders /{ id }
/ products
/ products /{ id }
/ customers
/ customers /{ id }
NOTE
You'll notice that the nouns in our object model have been represented as URIs. URIs shouldn't be
used as mini-RPC mechanisms and should not identify operations. Instead, you should use a com-
bination of HTTP methods and the data format to model unique operations in your distributed
RESTful system.
Defining the Data Format
One of the most important things we have to do when defining a RESTful interface is de-
termine how our resources will be represented over the wire to our clients. XML is perhaps
one of the most popular formats on the Web and can be processed by most modern lan-
guages, so let's choose that. JSON is also a popular format, as it is more condensed and
JavaScript can interpret it directly (great for Ajax applications), but let's stick to XML for
now.
Generally, you would define an XML schema for each representation you want to send
across the wire. An XML schema defines the grammar of a data format. It defines the rules
about how a document can be put together. I do find, though, that when explaining things
within an article (or a book), providing examples rather than schema makes things much
easier to read and understand.
Read and Update Format
The XML format of our representations will look a tiny bit different when we read or update
resources from the server as compared to when we create resources on the server. Let's look
at our read and update format first.
Common link element
Each format for Order , Customer , and Product will have a common XML element called
link :
Search WWH ::




Custom Search