Hardware Reference
In-Depth Information
Representational State Transfer
Underlying the HyperText Transfer Protocol (HTTP) is a principle known as Representa-
tional State Transfer , or REST . It's not a protocol—it's more of an architectural style for
information exchange. Though it started with the Web, it has applications in other areas.
Understanding a little about REST will not only help you understand other systems, it
will design your own communications protocols as well. Once you know about it, you
can never get enough REST in your life.
The basic idea of REST is this: there is a thing somewhere
on a network. Maybe it's a database, or maybe it's a
microcontroller controlling your household appliances,
like you made in the previous chapter. You either want to
know what state it's in, or you want to change its state.
REST gives you a way to describe, or represent , the state
of the thing on the Net, and to transfer that representation
to a remote user. REST is an addressing scheme for any
remote thing.
The Arduino would know that it should set digital pin 2 to
be an output, and set it high (1 =HIGH). In this scenario,
the Arduino is the server—serving you up representations
of its state—and you're the client.
There are three important elements to this exchange:
1. The representation (called a resource ) and its attributes
are separated by slashes. You can think of the attributes
like the properties of an object.
2. The verb is the request: whether you want to get some
information or change the state of the thing, you start
with the verb. The verbs are HTTP's verbs: GET, POST,
PUT, and DELETE (the last two are used less often).
3. The description is technology-independent. There's no
actual mention as to whether the resource is delivered
to you as an HTML page or XML from a web server, or
whether it's printed by a PHP or Ruby script on a server,
a C/C++ program running on an Arduino, or black
magic. It doesn't matter how the result is generated,
you just want to know what the state of things is, and
it's the server's job to do that.
You've been using REST already—it's what HTTP is all
about. You want to know about the thing, you make a
request to GET that information or to POST changes to
the thing. The thing responds to your request, either with
a representation of the state of affairs (for example, the
HTML page delivered by the air conditioner controller,
which included representations of the temperature and
the state of the thermostat), or by changing the state of
affairs (for example, by updating the thermostat setting).
In RESTful thinking, URLs are nouns that describe things,
and requests are the verbs that act on nouns. The prop-
erties of things are described in the URL, separated by
slashes. For example, here's a RESTful description of one
of an Arduino's pins:
The beauty of being technology-independent is that you
can use REST for just about any control interface. For
example, Open Sound Control, or OSC, a protocol for
musical controllers that's designed to supersede MIDI,
is RESTful. ACN, the Advanced Controller Networking
protocol designed to replace DMX512, is also RESTful. It's
also independent of the transport mechanism, and it can
be sent over Ethernet, serial, or any other physical data
transmission. REST provides a standard way of naming, or
addressing, things so that you keep using that addressing
scheme when you change environments, programming
tools, or network technologies. It's simple enough that you
can read it with a limited processor, and general enough
to describe most anything you want information about or
want to control.
/pin/A0/
If you want to know the state of that pin, you might say to
the Arduino:
GET /pin/A0/
The Arduino would then reply with the state of pin A0,
a number between 0 and 1023. Or, perhaps you want to
change the state of a digital output pin. You might do this:
POST /pin/D2/1/
Search WWH ::




Custom Search