I'm sorry Toivo, I understand your confusion I think. It stems from
the way the words 'state' and 'stateful' have been so hopelessly
In REST it is very clear what state means. You have resources located
at URIs and performing a GET on these resources retrieves a
representation of their state. There is no analogy to SOAP.
As Paul hinted earlier, a SOAP service is nothing but a bunch of
static methods being called through XML over HTTP. There is no
fundamental notion of state. SOAP can maintain state through cookies
and similar mechanisms but this is a poor substitute.
Why is this important?
This debate was originally about which methodology was more object
oriented. I was trying to demonstrate that REST is far more object
oriented than SOAP ever will be.
Here are my thoughts on REST and Resource Oriented Programming. This
email is very long so don't read it if you're in a hurry :)
1) Resources are objects. They expose methods (DoGet, DoPut,
DoDelete, DoPost, DoOptions, and DoTrace) which define a behavior and
they possess a well-defined and meaningful state.
2) Because all resources expose the same five methods polymorphism is
implicit. If you define a type of user and I want to retrieve
information about your type of user I call GET url($User). If I want
to update the representation of that user I call PUT url($User). If
later, Idecide to take your user resource type and extend it by
adding fields then the API does not change. To read the new user
subclass you call GET. To update it, you call PUT.
3) The five methods (discounting HEAD) exposed by HTTP can
collectively describe any given set of traditional OO methods. The
transformation from OO methods to HTTP methods can be automated to a
large extent. Here is the general algorithm I use:
3.1) Retrieve all accessor methods from the object which are of
the form 'getXXX()'. The set of all accessor methods can be described
by the single HTTP GET method.
3.2) Retrieve all mutator methods from the object which are of
the form 'setXXX()'. The set of all mutator methods can be described
by the single HTTP PUT method.
3.3) If the object is a collection, search for all methods of the
form 'Add(Object o)'. Based on the result of 3.1 wrt to 'o' for each
add method, then each method of the form Add(Object) can be described
by the single HTTP POST method.
3.4) Repeat step 3.3, but instead searching for Remove(Object)
methods which will be mapped to corresponding HTTP DELETE methods.
3.5) All methods which ask a question about the state of the
object can be safely ignored. Eg methods of the form IsXXX. Instead,
clients can simply retrieve the state of the object and perform
queries directly. Similarly, all methods which perform calculations
based on the state of the object (eg Circle.CalculateArea()) can be
safely ignored. Let the client perform calculations directly against
the state representation.
3.6) Examine all remaining methods. Any method which expresses
behavior must be decomposed into a resource transfer problem. The
classic example (that I continually encounter in my adventures in
REST) is the ShoppingCart. In OOP-land, it is common to have a
ShoppingCart class which exposes a CheckOut method. In ROP-land, you
cannot expose such a method. (You could using HTTP POST but you
shouldn't). Instead, the behavior of the CheckOut method must be
expressed by creating a new Order resource and referring to the
existing ShoppingCart resource. Thus the ShoppingCart.CheckOut method
is replaced by POSTing an OrderCollection resource to create a new
OrderResource. This is just an example.
This last step, step 3.6, cannot be automated and it's what makes
designing RESTful services so difficult IMO. Many developers do not
wish to take the time to perform the decompisition of behavioral
methods so they simply expose them directly. This often leads to many
problems. But this is the crux of REST: decomposing an API into a
resource manipulation problem and while I can't prove it, it's my
belief that all APIs can be completely decomposed into a resource
(BTW, consider the SOAP equivalent to checking out a shopping cart.
Because there is no real object model, the client usually ends up
calling a method CheckOut and passing a UUID of some sort or a simple
struct. This is hardly OOP--at best it is akin to "object-based" C
You wrote: 'With REST you can't just take any Java/C++/C# Object and
turn it into an easily used network accessible "thing".'
In fact, this is exactly what I do. Given a User class I can generate
a UserResource class. Given a UserCollection class I can generate a
User extends BusinessObject ---> UserResource extends HttpResource
get/set Username void DoGet()
get/set Email void DoPut()
get/set Realname void DoDelete()
The tools exist if you're willing to write them.
4) When constructing a restful webservice it is necessary to clearly
define what types of resources will exist and what operations may be
performed upon these resources. This is done by examining the nouns
in your problem domain and constructing resources that correspond to
your nouns. This is the process of object discovery--it is the same
process performed when constructing traditional object oriented
solutions. This suggests there is indeed a strong relationship
between resource oriented programming and object oriented
5) Now this is just a theory of mine and I need to explore it more,
but I suspect that what you call Resource Oriented Programming is
akin to the logical completion of what has been traditionally called
Object Oriented Programming. The "goal" of OOP is to encapsulate data
and behavior into a single logical component. Components then
interact by passing messages back and forth. Encapsulation works
because it allows complexity to be hidden (encapsulation is also
known as information hiding) and so clients only need to know about
the messages that go into and come out of a component and the state
of that component. So this is the ***fundamental value proposition of
encapsulation and OOP**: the amount of information a component A
needs to know about a component B is reduced to the set of B's
operations (the verb's that can be carried out against B) and B's
Now let's return to ROP.
The "essence" of Resource Oriented Programming is to reduce the
number of verbs in a system to a constant N (where N = 5 for HTTP) by
introducing many nouns. Agents in an ROP system interact by applying
these N verbs to this matrix of nouns. This is the **fundamental
value propisition of REST**: the amount of information a component A
needs to know about a component A has been reduced to B's state (and
the XML vocabulary used to describe that state).
It is a well known fact that loose coupling is the holy grail of
extremely complex (distributed) apps. The less two components know
about one another the better. Therefore I'd like to say that ROP
supercedes OOP because it has significantly reduced the amount of
information two components must know about one another by placing a
limit on the verbs a components can expose and requiring all
components to expose the same verbs. Therefore ROP-systems
**increase** loose-coupling and encapsulation. I'd even go so far as
to say that a well-defined ROP-system can be more "object-oriented"
than the analagous OOP-system.
Anybody who's ever built a large distributed app based on RPC and RMI
should be able to immediately appeaciate the super-encapsulation
achieved by ROP. Remember the three most common problems with RPC/RMI:
1) Interface Fragility. Component A needs to add or remove a
parameter to a method. When this happens, all components which depend
on Component A's interface must be updated to obtain its new
2) Inconsistency. (Unbounded Complexity). In RPC/RMI systems the
same logical operation can go by many different names. For example,
Component A might expose a Destroy() operation, Component B might
expose a Finalize() operation, and Component C might expose a Delete
() operation. This makes it very difficult for these components to be
tied together into a coherent solution by a virgin third party
because the virgin third party must take time to understand and
handle the slightly different interfaces of each. This should be
pretty clear: as the number of components grow the number of verbs in
the system approach infinity and so it becomes impossible for
newcomers to understand all the verbs exposed by the system and
therefore understand what the system can do. This completely destroys
what Sam Ruby calls "Manufactured Serendipity."
(I really can't stress the phenomenon of Manufactured Serendipity
enough. This is, I believe, the --point-- of the web. When you hide
information behind SOAP endpoints that information might as well not
be there. When you assign URLs to information it becomes possible for
virgin thirdparties to use the system in ways you never dreamed of
for example Google can now index that information (since it has URL)
and others can use tools like XInclude, XSLT, etc to manipulate that
3) Dynamic discovery. No matter what Microsoft et. al. may tell
you, true dynamic discovery is impossible with RPC because every RPC
service exposes its own set of methods and it is impossible to know
what these methods mean. There's no way a machine can look
at 'RetrievePurchaseOrder(Long poID)' and havy any clue what that --
That's just off the top of my head but those are three main flaws
I can think of when it comes to RPC/RMI system. Now look at each one
and apply ROP. 1 and 2 disappears because you no longer have
specialized interfaces -- all components expose the same verbs. 3
kind of disappears because these universal verbs have a well-defined
meaning. If a machine knows that the resource located at
is a type of purchase order then
it can infer that executing the GET method against that URL will
retrieve a representation of that purchase order. In this case it's
clear that the data backup problem becomes trivial to solve in
Toivo, hopefully at this point I've convinced you somewhat why I
think ROP is far more object oriented than RPC and in fact may be
more object oriented than OOP (as if that makes any sense). Also I
can honestly say that it's been my experience that, given a well-
defined object model to a business app, it's easier for me to devise
a RESTful webservice than a SOAP webservice which exposes that object
(continued in ROP vs RPC vs OOP pt 2)
--- In rest-discuss@y..., "Toivo \"Deutsch\" Lainevool"
> Where do you get the idea that SOAP services are stateless? I don't
> think there is any mention of state or statelessness in the SOAP
> I think a SOAP service can be just as statefull as a REST
> I missing something here?
> I'm also not sure what you mean by "By definition [SOAP Services]
> objects". I don't want to get argument about what an object is or
> isn't, but SOAP services are something you can use for doing object
> oriented decomposition of a problem, whether or not its stateless.
> > -----Original Message-----
> > From: inthedarkplace [mailto:inthedarkplace@y...]
> > > >
> > > > With REST you can't just take any Java/C++/C# Object and turn
> > into an
> > > > easily used network accessible "thing".
> > Actually you can and I do it all the time. I have automated tools
> > which can automagically generate the REST code given an object's
> > class. Also note that SOAP services are stateless. By definition
> > are not objects. Resources have states and they expose methods
> > (DoGet, DoPut, DoDelete, DoPost, DoTrace, DoOptions) which
> > behavior. After having done a lot of SOAP and REST hacking it's
> > evident to me and my team that REST is far more object oriented
> > SOAP. In REST you work with real objects, in SOAP you're
> > working with a class that defines arbitrary static methods.