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

Hierarchical resources

Expand Messages
  • Yannick Loiseau
    hie all, I know that this subject has already been discussed, but to summarize: How to represent hierarchical resources restfully? Here is the structure: /root
    Message 1 of 4 , Sep 1, 2002
    • 0 Attachment
      hie all,
      I know that this subject has already been discussed, but to summarize:
      How to represent hierarchical resources restfully?
      Here is the structure:

      /root
      +-- group 1
      | +-- attribute 1.a
      | |
      | +-- element 1.1
      | | +-- attribute 1.1.a
      | | |
      | | +-- attribute 1.1.b
      | |
      | +-- element 1.2
      | | +-- ....
      | +-- ...
      |
      +-- group 2
      | |
      | + element 2.1
      | |
      | +-- ...
      |
      +-- ...

      This could be an ldap directory (e.g address book) for example, or an 'ls
      -R' of an FTP server. The root url will be : http://my.server.com/root
      I think there is some points to consider:
      * What this url should return: some information about the resource, or a
      listing of its contents (groups). If a listing is allowed, this raise the
      recursive issue. Is recursively restful. I thought about these solutions:
      1. <root>
      some information
      <group1 xlink:href="url/to/group.1" />
      <group2 xlink:href="url/to/group.2" />
      ...
      </root>

      2.a <root>
      <group1>
      <attribute1a>value</attribute1a>
      <element11 xlink:href="url/to/element.1.1"/>
      ...
      <group2>...</group2>
      ...
      </root>
      2.b <root>
      <group1 attribute1a="value">
      <element11 xlink:href="url/to/element.1.1"/>
      ...
      <group2>...</group2>
      ...
      </root>

      3 <root>
      <group1>
      <attribute1a>value</attribute1a>
      <element11>
      <attribute11a>value</attribute11a>
      </element11>
      ...
      <group2>...</group2>
      ...
      </root>

      Note that they could be 3.b with attribute values as ``real" xml
      attributes, but this difference (between 2.a and 2.b is an other debate). I
      think the first solution is the more restful one. But I'd like to be able to
      save the resources for a local access, and to avoid to have to save
      multiples files, making links relatives, etc. This explain the 3rd solution
      (the 2nd one is just un hybrid, which is not very useful :) The question is:
      is it correct to make the 3rd solution available at
      http://my.server.com/root?recursive=true or
      http://my.server.com/root?recursive=2 where recursive=0 is the 1rst solution
      and recursive=1 the second one.

      * The other issue is: what should be the url to groups and elements (and
      possibly attributes).
      1. http://my.server.com/root/group1/element11
      2. http://my.server.com/root?group=1&element=11
      3. without the hierarchy http://my.server.com/root?attribute=11a
      directly

      and is an hybrid solution possible (e.g
      http://my.server.com/root/group1?element=11, or
      http://my.server.com/root/group1/element11?attribute=11a)

      I think that the path form (1) is better for access, since the query one
      (3) is better for search queries.

      To be more concrete, suppose that groups are contacts 'groups (which
      attribute is a description), elements are contacts and attributes are mail
      address, phone number, name and description. The goal is to allow the access
      to coordinates, groups or contacts (e.g a ldap gateway) and to save them to
      a single file (see first point) to local access.
    • S. Mike Dierken
      Separate the addressing from the XML representation. The difference between and value
      Message 2 of 4 , Sep 1, 2002
      • 0 Attachment
        Separate the addressing from the XML representation.

        The difference between <group1 attribute1a="value"> and
        <group1><attribute1a>value</attribute1a></group1> is a personal preference -
        unless you are conforming to someone else's schema/structure.

        If the goal is 'to allow the access to coordinates, groups or contacts (e.g
        a ldap gateway) and to save them to a single file (see first point) to local
        access' then your addressing doesn't have to directly mimic the storage
        structure - the addressing will reflect the needs of getting a lot or small
        amount of information and preserving links to other information.
        That is where your recursive=2 comes from (I'd use 'depth=2' as a name by
        the way, just for fun and DAV mimicry).

        > * The other issue is: what should be the url to groups and elements
        (and possibly attributes).
        You might try using local references (uri references, or 'fragments') via
        the '#' url character. If generating a representation of an attribute is
        moderately expensive, it may be better to return the whole element and allow
        addressing into this representation.
        http://my.server.com/root?group=1&element=11#attribute11a
        This returns a represenation of http://my.server.com/root?group=1&element=11
        and the local application needs to find the #attribute11a.





        ----- Original Message -----
        From: "Yannick Loiseau" <yloiseau@...>
        To: <rest-discuss@yahoogroups.com>
        Sent: Sunday, September 01, 2002 3:49 PM
        Subject: [rest-discuss] Hierarchical resources


        > hie all,
        > I know that this subject has already been discussed, but to summarize:
        > How to represent hierarchical resources restfully?
        > Here is the structure:
        >
        > /root
        > +-- group 1
        > | +-- attribute 1.a
        > | |
        > | +-- element 1.1
        > | | +-- attribute 1.1.a
        > | | |
        > | | +-- attribute 1.1.b
        > | |
        > | +-- element 1.2
        > | | +-- ....
        > | +-- ...
        > |
        > +-- group 2
        > | |
        > | + element 2.1
        > | |
        > | +-- ...
        > |
        > +-- ...
        >
        > This could be an ldap directory (e.g address book) for example, or an 'ls
        > -R' of an FTP server. The root url will be : http://my.server.com/root
        > I think there is some points to consider:
        > * What this url should return: some information about the resource, or
        a
        > listing of its contents (groups). If a listing is allowed, this raise the
        > recursive issue. Is recursively restful. I thought about these solutions:
        > 1. <root>
        > some information
        > <group1 xlink:href="url/to/group.1" />
        > <group2 xlink:href="url/to/group.2" />
        > ...
        > </root>
        >
        > 2.a <root>
        > <group1>
        > <attribute1a>value</attribute1a>
        > <element11 xlink:href="url/to/element.1.1"/>
        > ...
        > <group2>...</group2>
        > ...
        > </root>
        > 2.b <root>
        > <group1 attribute1a="value">
        > <element11 xlink:href="url/to/element.1.1"/>
        > ...
        > <group2>...</group2>
        > ...
        > </root>
        >
        > 3 <root>
        > <group1>
        > <attribute1a>value</attribute1a>
        > <element11>
        > <attribute11a>value</attribute11a>
        > </element11>
        > ...
        > <group2>...</group2>
        > ...
        > </root>
        >
        > Note that they could be 3.b with attribute values as ``real" xml
        > attributes, but this difference (between 2.a and 2.b is an other debate).
        I
        > think the first solution is the more restful one. But I'd like to be able
        to
        > save the resources for a local access, and to avoid to have to save
        > multiples files, making links relatives, etc. This explain the 3rd
        solution
        > (the 2nd one is just un hybrid, which is not very useful :) The question
        is:
        > is it correct to make the 3rd solution available at
        > http://my.server.com/root?recursive=true or
        > http://my.server.com/root?recursive=2 where recursive=0 is the 1rst
        solution
        > and recursive=1 the second one.
        >
        > * The other issue is: what should be the url to groups and elements
        (and
        > possibly attributes).
        > 1. http://my.server.com/root/group1/element11
        > 2. http://my.server.com/root?group=1&element=11
        > 3. without the hierarchy http://my.server.com/root?attribute=11a
        > directly
        >
        > and is an hybrid solution possible (e.g
        > http://my.server.com/root/group1?element=11, or
        > http://my.server.com/root/group1/element11?attribute=11a)
        >
        > I think that the path form (1) is better for access, since the query
        one
        > (3) is better for search queries.
        >
        > To be more concrete, suppose that groups are contacts 'groups (which
        > attribute is a description), elements are contacts and attributes are mail
        > address, phone number, name and description. The goal is to allow the
        access
        > to coordinates, groups or contacts (e.g a ldap gateway) and to save them
        to
        > a single file (see first point) to local access.
        >
        >
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > rest-discuss-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
      • jmay
        I don t believe that the REST style makes any recommendation regarding how resources should be represented as URIs. There is no correct answer, or even a
        Message 3 of 4 , Sep 2, 2002
        • 0 Attachment
          I don't believe that the REST style makes any recommendation regarding
          how resources should be represented as URIs. There is no "correct"
          answer, or even a "best" answer. It all depends on your application.

          Doctrine says: URIs should be considered as opaque. A URI like
          http://my.server.com/x742q/32ij5 might refer to "sub-element foo of
          sub-element bar of element xyzzy". Or not.

          Certainly I don't recommend explicit opaqueness as the Right approach
          in all cases. Embedding meaning in URIs can often be helpful, and
          improve application performance by avoiding the need for extra lookups
          in your code. But this is outside of the scope of REST.

          Appropriate punctuation (/ and ? and &) may be driven by your
          application as well. Is the structure pre-defined, or does it grow
          and change over time? Is the concept of searching even relevant, and
          can searches be made over sub-trees as well as the whole hierarchy?
          Are attributes defined from a fixed set, or are these variable as well?

          There's no right answer here.

          -Jason



          --- In rest-discuss@y..., "Yannick Loiseau" <yloiseau@f...> wrote:
          > How to represent hierarchical resources restfully?
          > [lengthy post snipped]
        • Jeff Bone
          ... By definition. But definitions are created by people, and people are fallible. Opaqueness is dogma, but it s not necessarily good engineering. I don t
          Message 4 of 4 , Sep 2, 2002
          • 0 Attachment
            On Monday, September 2, 2002, at 06:34 PM, jmay wrote:

            > Certainly I don't recommend explicit opaqueness as the Right approach
            > in all cases. Embedding meaning in URIs can often be helpful, and
            > improve application performance by avoiding the need for extra lookups
            > in your code. But this is outside of the scope of REST.

            By definition. But definitions are created by people, and people are
            fallible.

            Opaqueness is dogma, but it's not necessarily good engineering. I
            don't want to start another philosophical debate, but suffice to say
            that there are times when embedding information in URI is the path of
            least resistance (at worst) or perhaps even the best solution to the
            problem.

            Dogma evolves, and is (hopefully) eventually replaced by engineering
            and best practices.

            jb
          Your message has been successfully submitted and would be delivered to recipients shortly.