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

Re: [rest-discuss] Rebel

Expand Messages
  • Jeffrey Winter
    ... I m not sure that there is any hard-and-fast rule about how to employ the Accept: header, but I think the general use case is one in which the various
    Message 1 of 10 , Mar 1, 2003
      > As far as exports are concered I'd imagine that you could deal with the
      > issue of XBEL fragments vs conformant XBEL documents by using content
      > negotiation, rather than a separate URI space. Sending the appropriate
      > Accept: header would indicate whether a fragment or a standalone XBEL
      > document was required. Or would this be an abuse of Accept:? This
      > approach could also be used to specify 'flat' for neseted resource
      > expansions.

      I'm not sure that there is any hard-and-fast rule about how to employ
      the Accept: header, but I think the general use case is one in which
      the various resource respresentations are otherwise addressable on
      their own. For example, you PUT to

      /image/test.jpg
      /image/test.bmp
      /image/test.gif

      but GET from

      /image/test

      with an appropriate Accept header.

      Most of the examples I've seen of pushing the Accept: header much
      beyond this start to subtly introduce what amounts to a hidden
      address space.

      - Jeff
    • Jeffrey Winter
      ... That is an interesting idea, but I had poked around at the WebDAV spec and my reading of it was that Depth: was only supported on LOCK, COPY, MOVE and
      Message 2 of 10 , Mar 1, 2003
        > > This approach could also be used to specify 'flat' for neseted resource
        > > expansions.
        >
        >
        > One can use the "Depth:" dav header to specify the "flatness" of a
        > container...

        That is an interesting idea, but I had poked around at the WebDAV
        spec and my reading of it was that Depth: was only supported on
        LOCK, COPY, MOVE and PROPFIND.

        All in all, it seemed conceptually simpler to accomplish
        what I wanted without introducing all the semantics of any of
        the WebDAV stuff.

        - Jeff
      • Richard Padley
        ... This still would fit with the fragment vs complete doc issue - just take a couple of file extension, one for fragment (e.g. .frag), one for standalone
        Message 3 of 10 , Mar 3, 2003
          Jeffrey Winter wrote:
          > As far as exports are concered I'd imagine that you could deal with the
          > issue of XBEL fragments vs conformant XBEL documents by using content
          > negotiation, rather than a separate URI space. Sending the appropriate
          > Accept: header would indicate whether a fragment or a standalone XBEL
          > document was required. Or would this be an abuse of Accept:? This
          > approach could also be used to specify 'flat' for neseted resource
          > expansions.
          >
          >
          > I'm not sure that there is any hard-and-fast rule about how to employ
          > the Accept: header, but I think the general use case is one in which
          > the various resource respresentations are otherwise addressable on
          > their own. For example, you PUT to
          >
          > /image/test.jpg
          > /image/test.bmp
          > /image/test.gif
          >
          > but GET from
          >
          > /image/test
          >
          > with an appropriate Accept header.

          This still would fit with the fragment vs complete doc issue - just take
          a couple of file extension, one for fragment (e.g. .frag), one for
          standalone compliant doc (.e.g. .xml). Then

          GET /xbel/hello-world.frag

          will return just the fragment, and

          GET /xbel/hello-world.xml

          will return the standalone compliant doc. Whats more this maps
          completely to the approach of using the accept header, one just needs a
          couple of mime type (mabe there is a standard for the XBEL one already?)

          GET /xbel/hello-world
          Accept: application/x-xbel-fragment

          would give one representation, the other would be

          GET /xbel/hello-world
          Accept: application/x-xbel-standalone

          >
          > Most of the examples I've seen of pushing the Accept: header much
          > beyond this start to subtly introduce what amounts to a hidden
          > address space.

          Yes and no. I see nothing wrong with using Accept: to choose the
          representation you want - its much cleaner than using a filename,
          because it allows multiple representations to have the same URI. By
          choosing a different URI (xbel-export) yu've effectively gone down the
          filename-like route, the only difference being folder name instead of
          file-extension (neither of which should matter to a client as the URI is
          opaque).

          >
          > - Jeff
        • Jeff Bone
          ... Yet Accept: (and all header-based approaches) do nonetheless introduce another namespace and a fair bit of complexity as well. IFF the particular
          Message 4 of 10 , Mar 3, 2003
            On Monday, Mar 3, 2003, at 03:38 US/Central, Richard Padley wrote:

            > GET /xbel/hello-world
            > Accept: application/x-xbel-fragment
            >
            > would give one representation, the other would be
            >
            > GET /xbel/hello-world
            > Accept: application/x-xbel-standalone
            >
            >>
            >> Most of the examples I've seen of pushing the Accept: header much
            >> beyond this start to subtly introduce what amounts to a hidden
            >> address space.
            >
            > Yes and no. I see nothing wrong with using Accept: to choose the
            > representation you want - its much cleaner than using a filename,

            Yet Accept: (and all header-based approaches) do nonetheless introduce
            another namespace and a fair bit of complexity as well. IFF the
            particular representations in question can / should be regarded as
            "first-class" entities in their own right, distinguishing them from
            each other via different URI is certainly do-able.

            I'm playing with this with a current application. I've got a mess of
            little resources, all of which have various representations. This goes
            beyond mere MIME type to functional types; for example, a given piece
            of content might also have an "editor" representation which
            encapsulates the content in a Web-based interface for editing and
            saving said content. Hence, I've got URIs like:

            /~jbone/Journal/2003/03/01/33?repr=editor-xhtml
            /~jbone/Journal/2003/03/01/33?repr=printable-xhtml
            /~jbone/Journal/2003/03/01/33?repr=rss2.0
            /~jbone/Journal/2003/03/01/33?repr=xml-raw
            /~jbone/Journal/2003/03/01/33?repr=rdf-factset

            This allows all of these things to be directly accessed by simply
            GETting them, rather than having to dip into conneg. AND it works well
            for alternate representations that have some associated functionality,
            beyond just this or that static format.

            jb
          • Vincent D Murphy
            [started a new thread because this has nothing to do with Rebel..] ... i just thought i would chime in and mention that i am using a similar technique for web
            Message 5 of 10 , Mar 3, 2003
              [started a new thread because this has nothing to do with Rebel..]

              On Monday, March 3, 2003, at 03:01 PM, Jeff Bone wrote:
              > a given piece
              > of content might also have an "editor" representation which
              > encapsulates the content in a Web-based interface for editing and
              > saving said content. Hence, I've got URIs like:
              >
              > /~jbone/Journal/2003/03/01/33?repr=editor-xhtml

              i just thought i would chime in and mention that i am using a similar
              technique for web editing interfaces. i have found that it doesn't
              make sense to have only a form-oriented HTML representation because
              e.g. drop-downs are problematic (read: impossible) to use hyperlinks
              with, and a pure HTML representation (with no form HTML) doesn't let
              you do any editing unless you're running some fringe client agent like
              amaya.

              so i have a HTML representation, and put the form-HTML representation
              in a seperate resource. i look at the form as a subordinate resource
              rather than just another representation.

              i would be interested in hearing what others think of this, pros/cons
              etc. my original thought process was that HTML forms don't have their
              own mime-type, (e.g. text/html+forms) so conneg was not an option.
              <shrug>

              so i would have something like:
              /~jbone/Journal/2003/03/01/33/form

              a GET on this gets you a HTML page with a form rather than 'normal'
              HTML; this form's target attribute is set to

              /~jbone/Journal/2003/03/01/33

              the form does a POST but i pre-process this on the server to actually
              mean PUT.

              > /~jbone/Journal/2003/03/01/33?repr=rdf-factset
              >
              > This allows all of these things to be directly accessed by simply
              > GETting them, rather than having to dip into conneg. AND it works well
              > for alternate representations that have some associated functionality,
              > beyond just this or that static format.

              i was going to suggest that perhaps "Content-type" or something would
              be a better name than "repr" but deja-vu tells me this has come up on
              this list before.

              off-topic tangent: try
              http://www.google.com/search?q=rest-discuss+Content-type+Vincent
              google doesn't seem to have crawled any archives of rest-discuss;
              bummer. sometimes i hate yahoo groups. i wonder whether the archives
              are hidden from crawlers behind their ads.

              i do think its important that people use standard attribute name/values
              for this though. otherwise interoperability will suffer big time, IMHO.
            • Seairth Jacobs
              From: Jeff Bone ... When you say first-class entity , do you mean resource ? ... I use a similar technique with a new blog system I
              Message 6 of 10 , Mar 3, 2003
                From: "Jeff Bone" <jbone@...>
                >
                > Yet Accept: (and all header-based approaches) do nonetheless introduce
                > another namespace and a fair bit of complexity as well. IFF the
                > particular representations in question can / should be regarded as
                > "first-class" entities in their own right, distinguishing them from
                > each other via different URI is certainly do-able.

                When you say "'first-class' entity", do you mean "resource"?

                > I'm playing with this with a current application. I've got a mess of
                > little resources, all of which have various representations. This goes
                > beyond mere MIME type to functional types; for example, a given piece
                > of content might also have an "editor" representation which
                > encapsulates the content in a Web-based interface for editing and
                > saving said content. Hence, I've got URIs like:
                >
                > /~jbone/Journal/2003/03/01/33?repr=editor-xhtml
                > /~jbone/Journal/2003/03/01/33?repr=printable-xhtml
                > /~jbone/Journal/2003/03/01/33?repr=rss2.0
                > /~jbone/Journal/2003/03/01/33?repr=xml-raw
                > /~jbone/Journal/2003/03/01/33?repr=rdf-factset
                >
                > This allows all of these things to be directly accessed by simply
                > GETting them, rather than having to dip into conneg. AND it works well
                > for alternate representations that have some associated functionality,
                > beyond just this or that static format.

                I use a similar technique with a new blog system I wrote. In the case of
                "folder" resources, I have the following:

                /blog?form=addentry
                /blog?form=addfolder
                /blog?form=editfolder

                For "entry" resources, I have:

                /blog/12?form=editentry
                /blog/12?form=trackback

                In each of these cases, a form related to an aspect of the resource is
                returned. This would be equivalent to your "?repr=editor-xhtml", I think.

                Independently, I also allow the folders to be returned as RSS. In case the
                client is not using the Accept: header (my blog system supports conneg), you
                can append the following query to the folder:

                /blog?rss=0.91
                /blog?rss=0.92
                /blog?rss=0.93
                /blog?rss=2.0

                (depending on which version you want). I think this would be similar to
                your "?repr=rss2.0". I just use two different query parameters, but is
                otherwise the same. However, I still treat all of these representations as
                the same resource. I do not consider them sub-resources or anything like
                that. I agree that a form to add a subfolder looks a lot different from an
                rss feed, but who says that a given representation of a resource must convey
                all of that resource?

                Now, I do also have conneg support in the places that it can be used. For
                instance, submitting a request to a folder with an "Accept: text/xml", you
                will get back the RSS2.0 feed. Now, if I needed to return another xml
                representation which also used "text/xml" as the mime-type, I would probably
                have to fall back to the query string method.

                ---
                Seairth Jacobs
                seairth@...
              • Vincent D Murphy
                ... just found this; makes the point more clearly: http://bitworking.org/news/45
                Message 7 of 10 , Mar 3, 2003
                  On Monday, March 3, 2003, at 05:04 PM, Vincent D Murphy wrote:
                  > i was going to suggest that perhaps "Content-type" or something would
                  > be a better name than "repr" but deja-vu tells me this has come up on
                  > this list before.
                  >
                  > i do think its important that people use standard attribute name/values
                  > for this though. otherwise interoperability will suffer big time,
                  > IMHO.

                  just found this; makes the point more clearly:
                  http://bitworking.org/news/45
                • Seairth Jacobs
                  From: Jeff Bone ... When you say first-class entity , do you mean resource ? ... I use a similar technique with a new blog system I
                  Message 8 of 10 , Mar 3, 2003
                    From: "Jeff Bone" <jbone@...>
                    >
                    > Yet Accept: (and all header-based approaches) do nonetheless introduce
                    > another namespace and a fair bit of complexity as well. IFF the
                    > particular representations in question can / should be regarded as
                    > "first-class" entities in their own right, distinguishing them from
                    > each other via different URI is certainly do-able.

                    When you say "'first-class' entity", do you mean "resource"?

                    > I'm playing with this with a current application. I've got a mess of
                    > little resources, all of which have various representations. This goes
                    > beyond mere MIME type to functional types; for example, a given piece
                    > of content might also have an "editor" representation which
                    > encapsulates the content in a Web-based interface for editing and
                    > saving said content. Hence, I've got URIs like:
                    >
                    > /~jbone/Journal/2003/03/01/33?repr=editor-xhtml
                    > /~jbone/Journal/2003/03/01/33?repr=printable-xhtml
                    > /~jbone/Journal/2003/03/01/33?repr=rss2.0
                    > /~jbone/Journal/2003/03/01/33?repr=xml-raw
                    > /~jbone/Journal/2003/03/01/33?repr=rdf-factset
                    >
                    > This allows all of these things to be directly accessed by simply
                    > GETting them, rather than having to dip into conneg. AND it works well
                    > for alternate representations that have some associated functionality,
                    > beyond just this or that static format.

                    I use a similar technique with a new blog system I wrote. In the case of
                    "folder" resources, I have the following:

                    /blog?form=addentry
                    /blog?form=addfolder
                    /blog?form=editfolder

                    For "entry" resources, I have:

                    /blog/12?form=editentry
                    /blog/12?form=trackback

                    In each of these cases, a form related to an aspect of the resource is
                    returned. This would be equivalent to your "?repr=editor-xhtml", I think.

                    Independently, I also allow the folders to be returned as RSS. In case the
                    client is not using the Accept: header (my blog system supports conneg), you
                    can append the following query to the folder:

                    /blog?rss=0.91
                    /blog?rss=0.92
                    /blog?rss=0.93
                    /blog?rss=2.0

                    (depending on which version you want). I think this would be similar to
                    your "?repr=rss2.0". I just use two different query parameters, but is
                    otherwise the same. However, I still treat all of these representations as
                    the same resource. I do not consider them sub-resources or anything like
                    that. I agree that a form to add a subfolder looks a lot different from an
                    rss feed, but who says that a given representation of a resource must convey
                    all of that resource?

                    Now, I do also have conneg support in the places that it can be used. For
                    instance, submitting a request to a folder with an "Accept: text/xml", you
                    will get back the RSS2.0 feed. Now, if I needed to return another xml
                    representation which also used "text/xml" as the mime-type, I would probably
                    have to fall back to the query string method.

                    ---
                    Seairth Jacobs
                    seairth@...
                  Your message has been successfully submitted and would be delivered to recipients shortly.