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

Re: [rest-discuss] Re: restful way to create an association between 2 resources

Expand Messages
  • Karen
    ... Why are they mutually exclusive? So long as the machine side of things assumes the URI is opaque, I don t think there s a problem with using a non-opaque
    Message 1 of 14 , Nov 5, 2007
      On 11/5/07, Yohanes Santoso <yahoo-rest-discuss@...> wrote:
      > Is it just me or do all these discusions about URI form and pattern
      > seem to put undue emphasise on URI composition at the expense of
      > hypermedia-driven application state?

      Why are they mutually exclusive? So long as the machine side of
      things assumes the URI is opaque, I don't think there's a problem with
      using a non-opaque string as a shorthand for purposes of the
      discussion here. That's why I mentioned "aesthetics" - it ought only
      be us humans care what the thing looks like.

      (Of course, I may be a heretic for preferring non-opacity for the
      human side of things. If a human wants to construct an URL, more power
      to him, he's got a pretty sophisticated error-recovery system. If the
      same human wants to code his client app to construct the URL, it's his
      own darn fault things break when the schema changes - machines
      shouldn't mind the tedium of following a link trail every time, and
      aren't so good at figuring out what happened when things didn't work.
      Let all play to their strengths.)
    • Yohanes Santoso
      ... I don t think undue emphasise means exclusivity, and I am certainly not saying and suggesting that they are mutually exclusive. I didn t mean to take a
      Message 2 of 14 , Nov 5, 2007
        Karen <karen.cravens@...> writes:

        > On 11/5/07, Yohanes Santoso <yahoo-rest-discuss@...> wrote:
        >> Is it just me or do all these discusions about URI form and pattern
        >> seem to put undue emphasise on URI composition at the expense of
        >> hypermedia-driven application state?
        >
        > Why are they mutually exclusive?

        I don't think 'undue emphasise' means exclusivity, and I am certainly
        not saying and suggesting that they are mutually exclusive.

        I didn't mean to take a holier-than-thou attitude. I certainly has
        obsessed over the URI's look in the past, and I am still doing it at
        times.

        Rather, I want to know if more emphasise should be put on the
        hypermedia aspect.


        YS
      • Karen
        ... At the expense of seemed to imply that, I guess. But I don t see it as being a tradeoff at all. Unless you assume we have limited time to spend posting
        Message 3 of 14 , Nov 5, 2007
          On 11/5/07, Yohanes Santoso <yahoo-rest-discuss@...> wrote:
          > I don't think 'undue emphasise' means exclusivity, and I am certainly
          > not saying and suggesting that they are mutually exclusive.

          "At the expense of" seemed to imply that, I guess. But I don't see it
          as being a tradeoff at all. Unless you assume we have limited time to
          spend posting to the list, I suppose.

          But really, most of the time when it looks like we're discussing the
          trivialities of URI definition, what we're really looking at is
          defining the resources that are being exposed. And that's a big deal,
          I think, and there is more depth there than the simplicity of
          hypermedia's "put in links!" The latter's not unimportant, it's just
          that there's seldom anything to consider there.

          > Rather, I want to know if more emphasise should be put on the
          > hypermedia aspect.

          I won't argue with that. And it's something I struggle with in
          Wirebird: you can request a representation of any given resource...
          no, wait. TOO DARN MANY RE* WORDS IN REST!

          Ahem.

          You can request a page in any flavor ('scuse me while I sidestep
          jargon), either by specifying HTTP_ACCEPT or, if there are multiple
          valid choices there, by the extension, with text/html being the
          default (because Wirebird is both a web site and a service, intended
          for use with dumb semi-compliant browsers as well as
          as-yet-hypothetical smart/automated clients).

          The HTML version, logically enough, is intended for human consumption.
          In some ways, it's more hypermedia-complete than other versions,
          because it has forms defining precisely how it expects its POSTs and
          PUTs and DELETEs to happen (okay, so they're all overloaded POSTs, but
          you work with what you have, y'know?). In other ways, it has the
          potential to be less complete, since it's template-driven, and
          sometimes you don't want to overwhelm the user with options - but
          unless a template is actually broken, you can always "get there from
          here."

          The Perl and JSON versions, and the generic-XML version when I get off
          my lazy butt and implement it (yeah, you can tell where I fall on the
          JSON vs. XML wars: the lazy side), all just do a big fat dump of every
          value they've come up with for that particular representation... so
          they should be hypermedia-complete (when everything's finished,
          anyway), sometimes redundantly ("there's more than one way to get
          there from here.") In practice, they're not as complete as the HTML
          version because I can alter things in the template: "a href='<tmpl_var
          some_link>/addendum.html'" and such, but when I'm not being lazy those
          are supposed to find their way back into the raw values.

          It's the RSS and Atom versions that bother me. And maybe they
          shouldn't, since RSS (especially) isn't exactly a standard designed
          for such general use. (Atompub, on the other hand, is high on my list
          of "things I really need to investigate and, no doubt, implement")
          They don't really stand alone, though there's an RSS and Atom version
          of every page in the magic <link> headers. But, just as a
          for-instance, the RSS feed for a single "page" (in the Wirebird sense,
          meaning a single mailing-list/forum/newsgroup post, wiki page, blog
          entry, or blog comment) has no external links at all, since it's a
          leaf node:

          http://forum.wirebird.com/page/gamehawk/main/00000050.rss

          The feed is for page 50, which is also the sole entry in the feed.
          Now, granted, it doesn't make a great deal of sense to even *have* a
          feed at leaf-node level, but if you look at the HTML version:
          http://forum.wirebird.com/page/gamehawk/main/00000050.html
          you see there's twenty or thirty links to various other bits of
          Wirebird, near and far. Granted I don't need to stuff the entire
          category/group/topic tree into every RSS feed, but at least the
          breadcrumb trail would be nice. And packing it all into HTML in
          description fields seems like cheating. I know there's more RSS fields
          than I've gotten around to using (lazy!) but I don't know that there's
          enough to be hypermedia-complete across all the things Wirebird can
          serve (categories, groups, topics, threads, pages, author profiles,
          etc.).

          Or do I just rely on the fact that any RESTful client ought to be
          smart enough (on seeing the "Vary: Accept" and "Content-Location:
          http://forum.wirebird.com/page/gamehawk/main/00000050" headers) to ask
          for a different flavor, knowing that XML or JSON is more likely to get
          it something hypermedia-complete?
        • Jon Hanna
          ... It s not just you. I m a bit believer in having readable, hackable, and generally pleasant URIs, but its mostly off-topic for a list about REST.
          Message 4 of 14 , Nov 6, 2007
            Yohanes Santoso wrote:
            > Is it just me or do all these discusions about URI form and pattern
            > seem to put undue emphasise on URI composition at the expense of
            > hypermedia-driven application state?

            It's not just you. I'm a bit believer in having readable, hackable, and
            generally pleasant URIs, but its mostly off-topic for a list about REST.
          • Stephen Bannasch
            ... The uri form is an expression of how the resources are modeled. I am wrestling with how to expose access to be able to manipulate the many-to-many
            Message 5 of 14 , Nov 6, 2007
              At 1:15 PM -0500 11/5/07, Yohanes Santoso wrote:
              >Karen <karen.cravens@...> writes:
              >
              >> On 11/5/07, Yohanes Santoso <yahoo-rest-discuss@...> wrote:
              >>> Is it just me or do all these discusions about URI form and pattern
              >>> seem to put undue emphasise on URI composition at the expense of
              > >> hypermedia-driven application state?
              >>
              >> Why are they mutually exclusive?
              >
              >I don't think 'undue emphasise' means exclusivity, and I am certainly
              >not saying and suggesting that they are mutually exclusive.
              >
              >I didn't mean to take a holier-than-thou attitude. I certainly has
              >obsessed over the URI's look in the past, and I am still doing it at
              >times.
              >
              >Rather, I want to know if more emphasise should be put on the
              >hypermedia aspect.

              The uri form is an expression of how the resources are modeled. I am wrestling with how to expose access to be able to manipulate the many-to-many associations between two resources types when these associations are both:

              1) not properties of the original resource types
              2) implicitly created when the original resource types are created

              For me getting the uri form right relates to how I model the objects and express this modeling as RESTful resources.

              At 10:21 AM +0000 11/6/07, Jon Hanna also wrote:
              >It's not just you. I'm a bit believer in having readable, hackable, and
              >generally pleasant URIs, but its mostly off-topic for a list about REST.

              In my experience getting the domain model right and then working out the RESTful expression usually leads to uri forms that are readable and hackable. The essential

              In this thread I'm working out a model for RESTfully access to an element of my domain that I didn't see any existing design patterns for.

              I haven't been clear enough in my writing if you are interpreting my goals as creating "readable, hackable, and generally pleasant URIs" -- that's secondary.

              Regarding "hypermedia-driven application state" ... well ... I'm looking forward to accessing these RESTful resources from external applications soon. I won't be surprised if when I get there I'll find more that I need to change in how I am modeling many-to-many associations between resources.
            • Etan Wexler
              Stephen Bannasch wrote to rest-discuss in [rest-discuss] Re: restful ... You write about types but I think that you are thinking of the resources that belong
              Message 6 of 14 , Nov 7, 2007
                Stephen Bannasch wrote to rest-discuss in "[rest-discuss] Re: restful
                way to create an association between 2 resources" on 6 November 2007:

                > I am wrestling with how to expose access to be able to manipulate
                > the many-to-many associations between two resources types when
                > these associations are both:
                >
                > 1) not properties of the original resource types
                > 2) implicitly created when the original resource types are created

                You write about types but I think that you are thinking of the resources
                that belong to those types. In other words:

                "I am wrestling with how to manipulate the many-to-many associations
                between two resources when these associations are not properties of the
                original resources and are implicitly created when the original
                resources are created."

                Am I correct?

                > For me[,] getting the uri form right relates to how I model the objects and express this modeling as RESTful resources.

                The URIs that you expose and the methods that your origin server permits
                on the corresponding resources are your model. Whatever you do behind
                the curtain to implement that model is your private business. You can
                let the latter rule the former, but why would you?

                > In this thread I'm working out a model for [RESTful] access to an element of my domain that I didn't see any existing design patterns for.

                In this thread you've gotten the suggestion to expose the associations
                as resources. Let me advance another suggestion, albeit one that I
                prefer less than I prefer exposing the associations as resources.
                Suppose that you have
                subject 5, <http://www.example/subject-5>;
                subject 20, <http://www.example/subject-20>;
                activity 18, <http://www.example/activity-18>;
                a list of activities related to subject 5,
                <http://www.example/subject-5/activities>;
                a list of activities related to subject 20,
                <http://www.example/subject-20/activities>;
                a list of subjects related to activity 18,
                <http://www.example/activity-18/subjects>.
                Suppose that you have a user agent which has RESTfully discovered
                the subjects,
                the activity,
                the lists,
                the relationship between subject 5 and its list of activities,
                the relationship between subject 20 and its list of activities,
                the relationship between activity 18 and its list of subjects.
                Suppose that the representations of the subjects and of the activity
                have an expiration date that allows the relationships to hold throughout
                the examples to come.

                Consider the following HTTP exchange between the user agent and the
                origin server listening on TCP port 80 of Internet host www.example.

                GET http://www.example/subject-5/activities HTTP/1.1
                Host: www.example

                HTTP/1.1 200 OK
                Date: Tue, 06 Nov 2007 12:00:00 GMT
                Allow: HEAD, GET, PUT, POST, TRACE
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 0


                In the foregoing HTTP exchange, the user agent discovers that subject 5
                has no related activities.

                Consider the following HTTP exchange between the user agent and the
                origin server listening on TCP port 80 of Internet host www.example.

                GET http://www.example/subject-20/activities HTTP/1.1
                Host: www.example

                HTTP/1.1 200 OK
                Date: Tue, 06 Nov 2007 12:00:01 GMT
                Allow: HEAD, GET, PUT, POST, TRACE
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 0


                In the foregoing HTTP exchange, the user agent discovers that subject 20
                has no related activities.

                Consider the following HTTP exchange between the user agent and the
                origin server listening on TCP port 80 of Internet host www.example.

                GET http://www.example/activity-18/subjects HTTP/1.1
                Host: www.example

                HTTP/1.1 200 OK
                Date: Tue, 06 Nov 2007 12:00:02 GMT
                Allow: HEAD, GET, PUT, POST, TRACE
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 0


                In the foregoing HTTP exchange, the user agent discovers that activity
                18 has no related subjects.

                Consider the following HTTP exchange between the user agent and the
                origin server listening on TCP port 80 of Internet host www.example.

                POST http://www.example/subject-5/activities HTTP/1.1
                Host: www.example
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 32

                http://www.example/activity-18
                HTTP/1.1 200 OK
                Date: Tue, 06 Nov 2007 12:00:03 GMT
                Allow: HEAD, GET, PUT, POST, TRACE
                Content-Location: http://www.example/subject-5/activities
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 32

                http://www.example/activity-18

                In the foregoing HTTP exchange, the user agent adds activity 18 to the
                list of activities that relate to subject 5.

                Consider the following HTTP exchange between the user agent and the
                origin server listening on TCP port 80 of Internet host www.example.

                GET http://www.example/activity-18/subjects HTTP/1.1
                Host: www.example

                HTTP/1.1 200 OK
                Date: Tue, 06 Nov 2007 12:00:04 GMT
                Allow: HEAD, GET, PUT, POST, TRACE
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 30

                http://www.example/subject-5

                Eureka! In the foregoing HTTP exchange, the user agent discovers that
                activity 18 relates to subject 5. What the user agent does not know and
                does not need to know is that the origin server amended a list of
                subjects in reaction to an amendment to a list of activities.

                Consider the following HTTP exchange between the user agent and the
                origin server listening on TCP port 80 of Internet host www.example.

                POST http://www.example/activity-18/subjects HTTP/1.1
                Host: www.example
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 31

                http://www.example/subject-20
                HTTP/1.1 200 OK
                Date: Tue, 06 Nov 2007 12:00:05 GMT
                Allow: HEAD, GET, PUT, POST, TRACE
                Content-Location: http://www.example/activity-18/subjects
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 61

                http://www.example/subject-5
                http://www.example/subject-20

                In the foregoing HTTP exchange, the user agent adds subject 20 to the
                list of subjects that relate to activity 18.

                Can you guess what comes next? Consider the following HTTP exchange
                between the user agent and the origin server listening on TCP port 80 of
                Internet host www.example.

                GET http://www.example/subject-20/activities HTTP/1.1
                Host: www.example

                HTTP/1.1 200 OK
                Date: Tue, 06 Nov 2007 12:00:06 GMT
                Allow: HEAD, GET, PUT, POST, TRACE
                Content-Type: text/uri-list; charset=UTF-8
                Content-Length: 32

                http://www.example/activity-18

                Eureka again! In the foregoing HTTP exchange, the user agent discovers
                that subject 20 relates to activity 18. What the user agent does not
                know and does not need to know is that the origin server amended a list
                of activities in reaction to an amendment to a list of subjects.

                Before listing the exchanges, I wrote that I prefer exposing the
                associations as resources. One reason for my preference is the ease of
                denying (removing, ending, ...) an association when the association is
                addressable. In the scenario that I prefer, denying an association
                requires nothing more than a "DELETE" request. This operation is O(1);
                repeating this operation is clean and easy. In the scenario that I
                elaborated, denying an association requires a "PUT" request to submit a
                list which excludes the indication of the target association. The
                operation is O(n) and involves race conditions, causing undue headache
                for all parties.

                --
                Etan Wexler.
              Your message has been successfully submitted and would be delivered to recipients shortly.