REST stands for REpresentational State Transfer.
http://en.wikipedia.org/wiki/Representational_State_Transfer

A RESTful
web service is particularly easy to write clients for, for several of
reasons:

No application/client state is stored on the server. If
something unexpected happens during a server/client conversation, the
client doesn't have to worry about re-synching to the server's state.
Its logic can therefore be much simpler.

The interface is very
standardized - actions are limited to HTTP methods, and URLs represent
resources (nouns).

URLs are well-connected.

So, for instance, a
Wirebird client can visit a new Wirebird site, and discover (via a
standard GET) the categories on that Wirebird (via the
well-connectedness). It can then fetch the groups in each category, and
the topics in each group, and the posts in each topic, based on the
links in each response.

Using the standard HTTP methods means that the
client can create, edit, and delete items in a standard manner (a
well-written REST service is self-documenting, though we'll publish API
documents anyway.)

REST is chiefly aimed at the "machine web," but
Wirebird is intended for consumption by the original client app as
well: the human-directed web browser. A certain amount of client-side
scripting will improve the user's experience, but one of Wirebird's
goals is to operate in even the most basic browser, without scripting
(or with scripting turned off).