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

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

Expand Messages
  • Yohanes Santoso
    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
    Message 1 of 14 , Nov 5, 2007
      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?



      YS
    • 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 2 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 3 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 4 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 5 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 6 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 7 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.