Loading ...
Sorry, an error occurred while loading the content.

2330ROP vs RPC vs OOP pt 1

Expand Messages
  • inthedarkplace
    Sep 2, 2002
    • 0 Attachment

      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
      manipulation problem.

      (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
      UserCollectionResource. Eg...

      User extends BusinessObject ---> UserResource extends HttpResource
      get/set Username void DoGet()
      get/set Email void DoPut()
      get/set Realname void DoDelete()
      void DoOptions()

      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
      http://host/purchase-orders/3424242 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
      RESTful services.

      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)
      - itdp

      --- In rest-discuss@y..., "Toivo \"Deutsch\" Lainevool"
      <tlainevool@n...> wrote:
      > 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
      resource. Am
      > I missing something here?
      > I'm also not sure what you mean by "By definition [SOAP Services]
      are no
      > 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.
      > Toivo
      > > -----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.
    • Show all 64 messages in this topic