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

Re: [rest-discuss] Re: Evidence

Expand Messages
  • Mark Baker
    Oops, missed this. On to the examples ... ... Ok, I see what you re getting it. It s not any profound issue, it s just a misinterpretation of what I was
    Message 1 of 64 , Aug 31, 2002
      Oops, missed this. On to the examples ...

      > > In the stateless case, you could just take the offending message to
      > > court and leave everything else behind, because its meaning is
      > > independant of any conversation it may have been sent in.
      > Depending on what you mean, that gets tricky.
      > Simple case: shipment notification is dependent on order line which
      > it purports to fulfill. Claims of non-fulfillment would need both
      > the shipment notification and the order line.

      Ok, I see what you're getting it. It's not any profound issue, it's
      just a misinterpretation of what I was saying about only needing to
      take one message to court.

      In fact, you always need to take two things to court; the contract,
      and proof of breach. My point, which was obviously poorly stated, is
      that proof of breach can be demonstrated with a single message (the
      shipment notification, as I understand what one is). Of course, proof
      of a entering into a contract should also be able to be demonstrated
      with a single message too.

      > More complex case: non-fulfillment is covered by a long term
      > contract which provides penalties. So now the long-term contract
      > clause must be stated as well.

      Ok, but the messages that establish expectation of fulfillment, and
      notify about fulfillment both mean the same thing independant of the
      details of any contract that exists. But its meaning *does* depend
      upon the existence of such a contract, so you'd want to reference it.
      Presumably any standard format for this info would have a way to
      reference one or more non-fullfillment contracts - is that the

      > Are these ideas relevant to the issue raise?


      Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
      Ottawa, Ontario, CANADA. distobj@...
      http://www.markbaker.ca http://www.idokorro.com
    • inthedarkplace
      Toivo, I m sorry Toivo, I understand your confusion I think. It stems from the way the words state and stateful have been so hopelessly overloaded. In REST
      Message 64 of 64 , Sep 2, 2002

        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.
      Your message has been successfully submitted and would be delivered to recipients shortly.