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

Re: [rest-discuss] Objects at REST...

Expand Messages
  • Mark Baker
    REST was, at one time, called the HTTP Object Model according to Roy. And many of my RESTful designs are still motivated by my circa-1994 view of
    Message 1 of 17 , Mar 12, 2008
    • 0 Attachment
      REST was, at one time, called the "HTTP Object Model" according to
      Roy. And many of my RESTful designs are still motivated by my
      circa-1994 view of distributed objects (before I got the Web);
      identifiable things, on a network, which react to messages sent to
      them.

      Mark.
    • Andrzej Jan Taramina
      ... The power of REST comes from the constraints that it enforces. There are only 4 methods, using HTTP, 5 if you include patch and a few more if you use
      Message 2 of 17 , Mar 12, 2008
      • 0 Attachment
        Lawrence:

        > I guess thinking about resources as objects and verbs as methods is
        > already within the boundaries of the REST architecture.
        > What do you mean specifically?

        The power of REST comes from the constraints that it enforces. There are
        only 4 methods, using HTTP, 5 if you include patch and a few more if you use
        WebDav. Those rarely map to object methods which are much more prolific in
        any domain model I have seen. OO does not enforce REST constraints, so
        trying to shoehorn and OO model into a REST approach is suboptimal at best.

        REST is not just resources per se, meaning URI-based addressing (which point
        to a conceptual resource), but also implies the representations that are
        returned when you reference a resource (uring a URI).

        Representations could be a direct mapping from OO models, but are unlikely to
        fit the needs of more complex machine to machine integration scenarios, since
        different systems will have different domain/object models, thus
        necessitating transformations between them. The better way to handle that is
        typically to have a canonical representation format between systems. It
        resolves the n-squared transformations issue if you don't go that way.

        BTW...my comments and focus tends to be oriented to the integration space,
        and not to the Web UI space, the latter being a much simpler issue to solve.
        Andrzej Jan Taramina
        Chaeron Corporation: Enterprise System Solutions
        http://www.chaeron.com
      • Andrzej Jan Taramina
        ... Typically not, in my experience. Objects are finer grained and designed for purposes other than external interface needs. ... My point here is that the
        Message 3 of 17 , Mar 12, 2008
        • 0 Attachment
          Alexander said:

          > if you are dealing with specific objects, I guess they're
          > resources like other resources, no?

          Typically not, in my experience. Objects are finer grained and designed for
          purposes other than external interface needs.

          > I think this more comes down to the definition of an object. Is there
          > a difference between an object and a resource? In the broad definition
          > of "resource", then no. In terms of REST, you can perfectly well
          > design objects that cater to that architectual style. The problem is
          > that "object" can be a lot of things, and specifically things that
          > don't fit into the REST way of doing things even if you expose them
          > through it.

          My point here is that the potential for abuse is too high. The OO folks will
          go ahead and design object models the way they always have, or will reuse
          existing models, and then just slap some HTTP on top of them with some URLs
          that reference those objects, and will REST on the 7th day.

          And then the distributed systems granularity and RPC issues will raise their
          ugly heads yet again.

          At least, in the real world, that is my prediction of what the Objects at
          REST suggesting will inevitably lead to.

          > Again, we're back to the old "if done right, then yes, and if done
          > wrong, then no" explanation.

          I predict way more wrong than right will be inflicted on business
          stakeholders and IT management with this approach. ;-)

          Andrzej Jan Taramina
          Chaeron Corporation: Enterprise System Solutions
          http://www.chaeron.com
        • Andrzej Jan Taramina
          ... That s the start of a very slippery slope. You re basically encouraging the OO folks to tunnel RPC over HTTP. I think we ve had enough discussions of why
          Message 4 of 17 , Mar 12, 2008
          • 0 Attachment
            Daniel suggests:

            > otherwise we treat methods as subordinate URLs of
            > the parent objects (e.g. /articles/1/publish()), but it only accepts
            > GET (we return a representation to fill the parameters and submit it,
            > usually is a xhtml form but it can be something else for other
            > media-types) and POST for invocation responding with redirect. It will
            > emphasize not using RPC style methods but if you must it should use
            > safe semantics.

            That's the start of a very slippery slope. You're basically encouraging the
            OO folks to tunnel RPC over HTTP.

            I think we've had enough discussions of why that is not such a good idea on
            the rest forums already.

            But you just proved my point...thanks!

            > Obviously I'm biased for it but I think it's a good way to develop an
            > application, because the user's interface will map the domain model.

            That doesn't work in the world of machine to machine communications, since it
            is rare that disparate systems have common domain or object models.

            The better approach in that scenario is to design a data representation
            format that is better suited to the integration and transmission of
            information, rather than cater to internal implementation models on both
            sides.

            > As we can use URIs to identify objects we can save those in other
            > systems, so we are planning to use URIs for every inter application
            > references, which lends itself to very easy integration.

            I beg to differ. Common/consistent URI's are a help, but a properly designed
            data representation, with concomittent semantic definitions, independent of
            back end domain/object models is what makes integration easier, though even
            at the best of times, integration is still hard.


            > Also if the
            > only interface to your app is via REST, everything can be an WS
            > without additional effort.

            What you're doing isn't REST for the most part. It's using HTTP as a
            transport mechanism for RPC and inter-object distributed communications.

            It's also great because you think much more
            > about your domain and don't worry with user interfaces, because this
            > problem is solved, so essentially you know that in the interface you
            > can just navigate via URIs and find what do you want (e.g.
            > /authors/Joe_Blogger/posts?published=false) which makes much easier to
            > write ajax widgets in the app without up front design.

            You are mixing metaphors. Integration is not an Ajax-based activity
            (usually), since Ajax is geared towards user UIs, not machine to machine
            integration, the latter being the much harder problem to solve, and providing
            much more benefit when it is solved (think healthcare for a good example of
            this).


            Andrzej Jan Taramina
            Chaeron Corporation: Enterprise System Solutions
            http://www.chaeron.com
          • Daniel Yokomizo
            On Wed, Mar 12, 2008 at 6:42 PM, Andrzej Jan Taramina ... I m not encouraging anything. As I said the primary method of interaction is basically REST using
            Message 5 of 17 , Mar 12, 2008
            • 0 Attachment
              On Wed, Mar 12, 2008 at 6:42 PM, Andrzej Jan Taramina
              <andrzej@...> wrote:
              >
              > Daniel suggests:
              >
              > > otherwise we treat methods as subordinate URLs of
              > > the parent objects (e.g. /articles/1/publish()), but it only accepts
              > > GET (we return a representation to fill the parameters and submit it,
              > > usually is a xhtml form but it can be something else for other
              > > media-types) and POST for invocation responding with redirect. It will
              > > emphasize not using RPC style methods but if you must it should use
              > > safe semantics.
              >
              > That's the start of a very slippery slope. You're basically encouraging the
              > OO folks to tunnel RPC over HTTP.

              I'm not encouraging anything. As I said the primary method of
              interaction is basically REST using whatever verbs you are want to
              work with (e.g. HTTP, WebDAV), but there's a escape clause, which is
              different from encouraging. As I said it only supports POST, which
              gives almost no guarantees and it return a 303 if there's a return to
              a know resource (no body in any case), so the user of the framework
              must work with resources.

              REST is an architectural choice that don't suit all needs, as a
              framework provider I need to either address this (which I decided to
              do in a way that is semantically correct) or ignore it and let the
              programmers come with a thousand non-conforming solutions.

              > I think we've had enough discussions of why that is not such a good idea on
              > the rest forums already.
              >
              > But you just proved my point...thanks!
              >
              >
              > > Obviously I'm biased for it but I think it's a good way to develop an
              > > application, because the user's interface will map the domain model.
              >
              > That doesn't work in the world of machine to machine communications, since it
              > is rare that disparate systems have common domain or object models.

              It doesn't matter if the user is a machine or a human. If the model we
              use to expose the resources is different from the domain model,
              otherwise the programmer have to write especialized code to do the
              mapping. It's the same issue with ORM, this kind of impedance mismatch
              always requires more work.

              > The better approach in that scenario is to design a data representation
              > format that is better suited to the integration and transmission of
              > information, rather than cater to internal implementation models on both
              > sides.
              >
              >
              > > As we can use URIs to identify objects we can save those in other
              > > systems, so we are planning to use URIs for every inter application
              > > references, which lends itself to very easy integration.
              >
              > I beg to differ. Common/consistent URI's are a help, but a properly designed
              > data representation, with concomittent semantic definitions, independent of
              > back end domain/object models is what makes integration easier, though even
              > at the best of times, integration is still hard.

              Instead of sending <customer id='XXX'/> we respond with <customer
              ref='/customers/XXX'/> which is the REST approach. It's easier to have
              integration if we know that every resource is sent with its
              corresponding URI.

              > > Also if the
              > > only interface to your app is via REST, everything can be an WS
              > > without additional effort.
              >
              > What you're doing isn't REST for the most part. It's using HTTP as a
              > transport mechanism for RPC and inter-object distributed communications.

              Why do you think so? If I have all my operations working on resources
              and I'm able to issue a DELETE /orders/XXX, it can work if the client
              is a browser or another app. The whole idea behind RESTful Web
              Services is about this. My apps are resource oriented, the only usage
              of POST in the app I'm working right now is when I want to create new
              resources (i.e. POST /resources). To my app it doesn't matter if the
              request comes from a browser or another machine, that's why I say that
              I have no effort providing WS for everything.

              > It's also great because you think much more
              > > about your domain and don't worry with user interfaces, because this
              > > problem is solved, so essentially you know that in the interface you
              > > can just navigate via URIs and find what do you want (e.g.
              > > /authors/Joe_Blogger/posts?published=false) which makes much easier to
              > > write ajax widgets in the app without up front design.
              >
              > You are mixing metaphors. Integration is not an Ajax-based activity
              > (usually), since Ajax is geared towards user UIs, not machine to machine
              > integration, the latter being the much harder problem to solve, and providing
              > much more benefit when it is solved (think healthcare for a good example of
              > this).

              Ajax is just an example. When I talked about ease of integration it
              was an earlier point. My point is if you have a generic way to
              exposing your domain via arbitrary composable URIs you don't need to
              predict that in some place of yoru system you'll need to provide a
              list of something filtered by some arbitrary criteria, the framework
              just maps the URI to the objects, filter the available results,
              chooses the response's content type using negotiation and the
              registered representations for the resulting object and gives it to
              the user. As an example you can build a mashup in another app that
              calls an arbitrary URI of your app and gets the result as XML or JSON
              or whatever. As the URI represents object navigation is possible to
              just GET /blogs/XXX/posts/YYY/author and get a JSON which can be used
              by a javascript widget or another app, instead of doing GET /blogs/XXX
              parse the results, GET /posts/YYY parse the results and then GET
              /authors/ZZZ.

              > Andrzej Jan Taramina
              > Chaeron Corporation: Enterprise System Solutions
              > http://www.chaeron.com

              Daniel Yokomizo.
            • Alexander Johannesen
              ... On Wed, Mar 12, 2008 at 10:42 PM, Andrzej Jan Taramina ... I can agree on the former, but not generally on the latter. However, I was more pointing to the
              Message 6 of 17 , Mar 13, 2008
              • 0 Attachment
                > > if you are dealing with specific objects, I guess they're
                > > resources like other resources, no?

                On Wed, Mar 12, 2008 at 10:42 PM, Andrzej Jan Taramina
                <andrzej@...> wrote:
                > Typically not, in my experience. Objects are finer grained and designed for
                > purposes other than external interface needs.

                I can agree on the former, but not generally on the latter. However, I
                was more pointing to the fact that the word "resource" is really
                whatever you make of it, including objects (whatever you make "object"
                out to be). :)

                > My point here is that the potential for abuse is too high.

                Not sure that this RESTful objects thing is any more prone to abuse
                (i.e; wrong use) than any other thing out there. HTTP by itself is
                abused all the time, even the OO paradigm is overly abused by most
                developers anyway. Unfortunately for the human race it requires proper
                knowledge to do things well. There's always some smartness that goes
                with every job well done, no matter what field, profession or
                situation. Guns don't kill people; bullets do. Are you saying the
                accessibility of our tool are to blame for the abuse of the tool?

                > The OO folks

                Who are they?

                > will
                > go ahead and design object models the way they always have, or will reuse
                > existing models, and then just slap some HTTP on top of them with some URLs
                > that reference those objects, and will REST on the 7th day.

                Hmm, aren't you more saying they won't REST on the 7th day? :)

                ...

                > I predict way more wrong than right will be inflicted on business
                > stakeholders and IT management with this approach. ;-)

                Given the knowledge business stakeholders / owners and IT management
                in general show on REST, I'd say we're safe for a long time still. :)
                If they don't understand the goodness of REST, then they're not
                capable of understanding the trouble with not doing it right either.


                Alex
                --
                ---------------------------------------------------------------------------
                Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
                ------------------------------------------ http://shelter.nu/blog/ --------
              • Steve Bjorg
                ... There are graduations of this. For instance, URIs used on spaces.live.com are SO machine focused that it causes gag reflexes to visitors. :) I agree with
                Message 7 of 17 , Mar 13, 2008
                • 0 Attachment
                  On Mar 12, 2008, at 2:42 PM, Andrzej Jan Taramina wrote:

                  >> Second, I know I am in the minority here, but pretty URIs are
                  >> irrelevant. ...
                  >
                  > I'm a bit ambivalent on this comment. Machine to machine, pretty
                  > URI's are
                  > quite irrelevant. But when it comes to testing machine to machine
                  > integrations, debugging and the like, which is conducted by
                  > meatware, pretty
                  > URI's can provide some real productivity and value. (snip) So why
                  > not make 'em pretty....doesn't take much more
                  > effort and can have some decent payback.

                  There are graduations of this. For instance, URIs used on
                  spaces.live.com are SO machine focused that it causes gag reflexes to
                  visitors. :)

                  I agree with you 100% that it is a nice thing to have (especially
                  when you need to look under the hood). I only use (and sometimes
                  abuse) REST for machine to machine interactions. In that context,
                  "pretty" doesn't scale as services are dynamically generated and
                  assembled.

                  > So what you are saying is that the exposed interfaces and common
                  > lingua
                  > franca between such services/apps is what is key. I subscribe to
                  > that,
                  > especially in the integration space.

                  Yes. That's exactly it.

                  > Nicely put, Steve!

                  Thanks! When I reposted it on my blog, I realized how poor my
                  command of grammar is before morning coffee. :) So thanks for
                  powering through it!
                  A cleaned up version is here:
                  http://www.mindtouch.com/blog/2008/03/12/objects-at-unrest/

                  Also, for the curious, a primer on how we build our software using
                  RESTful services is here:
                  http://wiki.mindtouch.com/Technology


                  Cheers,

                  - Steve

                  --------------
                  Steve G. Bjorg
                  http://wiki.mindtouch.com
                  http://wiki.opengarden.org
                • Steve Bjorg
                  ... The problem in your thinking here is that you re still partitioning behavioral into sets of methods. If you fix the set of methods to HTTP verbs (GET,
                  Message 8 of 17 , Mar 13, 2008
                  • 0 Attachment
                    On Wed, Mar 12, 2008 at 6:42 PM, Andrzej Jan Taramina
                    <andrzej@...> wrote:


                     Daniel suggests:


                    otherwise we treat methods as subordinate URLs of
                    the parent objects (e.g. /articles/1/publish()), but it only accepts
                    GET (we return a representation to fill the parameters and submit it,
                    usually is a xhtml form but it can be something else for other
                    media-types) and POST for invocation responding with redirect. It will
                    emphasize not using RPC style methods but if you must it should use
                    safe semantics.


                     That's the start of a very slippery slope.  You're basically encouraging the
                     OO folks to tunnel RPC over HTTP.


                    I'm not encouraging anything. As I said the primary method of
                    interaction is basically REST using whatever verbs you are want to
                    work with (e.g. HTTP, WebDAV), but there's a escape clause, which is
                    different from encouraging. As I said it only supports POST, which
                    gives almost no guarantees and it return a 303 if there's a return to
                    a know resource (no body in any case), so the user of the framework
                    must work with resources.

                    The problem in your thinking here is that you're still partitioning behavioral into sets of "methods."  If you fix the set of methods to HTTP verbs (GET, PUT, DELETE, POST), the only way you can partition the behavioral space is by topologies of resources (i.e. relationships).

                    Another way to think about is that you're building your software out of a few building blocks that you _cannot_ add behavior to.  These building blocks are entities (GET, PUT) and collections (GET, PUT, POST, DELETE).

                    In this view of the world, there is no URI that corresponds to the "publish" method found in OO.  However, "the act of publishing" is defined as POSTing a new entity to the publications collection.  (Reading ahead, it appears you're already well familiar with this approach).


                    Obviously I'm biased for it but I think it's a good way to develop an
                    application, because the user's interface will map the domain model.


                     That doesn't work in the world of machine to machine communications, since it
                     is rare that disparate systems have common domain or object models.


                    It doesn't matter if the user is a machine or a human. If the model we
                    use to expose the resources is different from the domain model,
                    otherwise the programmer have to write especialized code to do the
                    mapping. It's the same issue with ORM, this kind of impedance mismatch
                    always requires more work.

                    Having to "specialized code to do the mapping" is exactly what this is about.  If you don't, you're doomed because you're forcing everyone to buy into your view of the world.  In REST, there are many views of the world (representations), but none of them are necessarily the state of the world (the resource).

                    Coupling at the representation level is the weakest, and therefore the most flexible way to interface communicating systems.



                     The better approach in that scenario is to design a data representation
                     format that is better suited to the integration and transmission of
                     information, rather than cater to internal implementation models on both
                     sides.



                    As we can use URIs to identify objects we can save those in other
                    systems, so we are planning to use URIs for every inter application
                    references, which lends itself to very easy integration.


                     I beg to differ.  Common/consistent URI's are a help, but a properly designed
                     data representation, with concomittent semantic definitions, independent of
                     back end domain/object models is what makes integration easier, though even
                     at the best of times, integration is still hard.


                    Instead of sending <customer id='XXX'/> we respond with <customer
                    ref='/customers/XXX'/> which is the REST approach. It's easier to have
                    integration if we know that every resource is sent with its
                    corresponding URI.


                    Also if the
                    only interface to your app is via REST, everything can be an WS
                    without additional effort.


                     What you're doing isn't REST for the most part.  It's using HTTP as a
                     transport mechanism for RPC and inter-object distributed communications.


                    Why do you think so? If I have all my operations working on resources
                    and I'm able to issue a DELETE /orders/XXX, it can work if the client
                    is a browser or another app. The whole idea behind RESTful Web
                    Services is about this. My apps are resource oriented, the only usage
                    of POST in the app I'm working right now is when I want to create new
                    resources (i.e. POST /resources). To my app it doesn't matter if the
                    request comes from a browser or another machine, that's why I say that
                    I have no effort providing WS for everything.

                    Hmm, that was not the impression I got from the /articles/1/publish example given above.  Maybe this is a case of vehement agreement?


                    - Steve

                    --------------
                    Steve G. Bjorg


                  • Andrzej Jan Taramina
                    ... Obviously the case here. GIven that most of us sling code and thus are quite familiar with the need for specificity, both at syntactic and semantic levels,
                    Message 9 of 17 , Mar 14, 2008
                    • 0 Attachment
                      MIchael:

                      > It's pretty clear to me that the people who chose the words "object" and
                      > "resource" were both trying to make the concepts as general as they could
                      > possibly make them, and therefore by intent they are equivalent. If there is a
                      > difference, then I don't think it's one that the originators of the terms
                      > intended.

                      Obviously the case here.

                      GIven that most of us sling code and thus are quite familiar with the need
                      for specificity, both at syntactic and semantic levels, it is rather
                      dismaying to see how prevalent "loose language", overloaded/opaque personal
                      definitions and vague conceptual idioms are when discussing topics like
                      Objects at REST.

                      It's no wonder that the software world is in such a mess, and that the
                      business folks, for the most part, ignore us.

                      This has been a good thread, with some interesting insights from many
                      quarters. Time to give it a REST, at least from my end. ;-)

                      Andrzej Jan Taramina
                      Chaeron Corporation: Enterprise System Solutions
                      http://www.chaeron.com
                    Your message has been successfully submitted and would be delivered to recipients shortly.