API - architectural model question

There are those in the Web space who believe REST models are best,
pointing to the various benefits of having a stateless (and cacheable)
form of interaction. Avoiding the need for the server to maintain some
state information (i.e. sessions) creates a more scalable solution.

Advocates of RPC approaches will point to the broad support for
client-server architecture, and support for distributed OO methodology
through RMI.

People familiar with stateful (session) designs will point to the
advantages for access control: authorisation, followed by a series of
interactions and finally session closure.

I raise these thoughts in order to focus some minds on the API
requirements. Some of the interface methods appear to be lightweight,
once-off, stateless operations. Fortunately these appear to be the parts
of the interface that will be exercised most (i.e. the retrieval of
device descriptions). Others, such as the administrative functions,
would appear to work well with stateful approaches, and may demand
support for transactions. The requirements for the optional "structures"
part of the API may suggest other architectural approaches.

While I would like to see a simple API result from our work, such
simplicity should not threaten the stability, scalability or
extensibility of the solution.

The preparatory work we have done to initiate an ontology, and the
process we are about to activate that will permit a core vocabulary to
be created, is an important input to the API as it will inform our
choice/creation of data types. Nevertheless, I believe we also need to
look at the architectural model of the API, and if necessary split it
into multiple models (e.g. one for data retrieval and one for
management).

Thoughts from the group and our public community are welcome.

---Rotan.