Hardware Reference
In-Depth Information
A Web-Based Device
Imagine you're building a device that controls the window
blinds in your office. There are 12 windows, each with its
own blind. The blinds can be positioned variably, in a range
from 1 to 10. The client can get the state of any blind, or
you can set it. The URLs to see the state of the windows
might look like this.
There's another advantage to REST when designing
websites: if you change the programming environment you
use to run your site, you don't have to change the URLs.
The client never sees the .php, .rb (Ruby), or .pl (Perl) file
extension, so it doesn't know or care what programming
environment powers your service. If you want to change
languages, go ahead! The site structure can stay the same.
To design RESTfully on the Web, think of the site or device
you're making in terms of its properties, and come up with
an addressing scheme that gives clients access to view
and change those properties appropriately. Practically, what
it means is that all the URLs of your site end at the
/
. There's
no index.html (or anything .html), and no GET query string.
Query parameters are passed using POST, and they're
generally the last item in the address, as you'll see below.
Following are two examples: one is a traditional website
and the other is a physical device on a network.
To see them all at once:
http://mywindows.example.com/window/all
To see an individual window (window number 2):
http://mywindows.example.com/window/2
To set a window's blind halfway down:
http://mywindows.example.com/window/2/50
A Traditional Web Service
Perhaps you're making a social media site for runners to
compare their daily runs. As part of it, each runner has a
profile with various attributes for each day's run: the date
(day, month, and year), the distance of the run, and the
time of the run. For a run on 31 January 2012, the URLs to
address those attributes might look like this.
To close them all:
http://mywindows.example.com/window/all/0
If you don't like these particular addressing schemes,
you could make your own, of course. Just follow the basic
RESTful style of
/object/attribute/newValue
to get the
value of a parameter, and
/object/attribute/newValue
to
set it.
To get the distance:
http://myrun.example.com/runnerName/31/1/2012/
distance/
What the actual interface returned by the URL looks like is
up to you. You might choose to make a graphic that shows
images of the windows with blinds, or you might show the
result in text only. RESTful architecture just determines
where to find something, not what you'll find there.
To set the distance to 12.56km:
http://myrun.example.com/runnerName/31/1/2012/
distance/12.56
RESTful addresses are designed to be easy for a computer
to parse. All you have to do is to separate the incoming
request into substrings on the slashes, look at each
substring to see what it is, and act appropriately on the
substrings that follow it. They're also easy for people to
read. A URL like the ones above is much more comprehen-
sible than the equivalent GET request:
To set the time to 1 hour, 2 minutes, 34 seconds:
http://myrun.example.com/runnerName/31/1/2012/
time/1:02:34
Notice how you can tell a call that gets the value of a
parameter from one that sets the value: the former has
nothing following the name of the parameter.
http://myrun.example.com/?runnerName=George&day=
31&month=1&year=2012&distance=12.56
The project that follows shows you how to set up a
PHP-based server that can parse RESTful addresses.
X
