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

Re: [rest-discuss] Switching content type

Expand Messages
  • Nic Ferrier
    ... Ah right... I see. Clearly the Accept header applies to any HTTP client. I don t think that makes your examples wrong. ... No. I don t think
    Message 1 of 27 , Jul 19, 2005
    • 0 Attachment
      toydi <iamstupidiot@...> writes:

      > I'm still trying to study more details about content negotiation in HTTP/1.1
      > But as far as i know now, an appropriate way for server to handle Accept tag is
      > to aware and understand the 'relative quality factor'.
      >
      > Any HTTP/1.1 client is allowed to append a */* in Accept tag.
      > Therefore, it's incorrect to assume a client is a web browser by
      > checking on */*, and return a default HTML representation. (which i
      > wrote in previous thread)

      Ah right... I see. Clearly the Accept header applies to any HTTP
      client. I don't think that makes your examples wrong.


      > Well, here's a scenario:
      >
      > Suppose a RESTful server provides both ATOM and HTML version of a
      > hacking tutorial with URL: http://foo/tutorials/hacking101.
      >
      > Any client (including browser) can get the document (ATOM or HTML) by:
      >
      > GET /tutorials/hacking101
      > Accept:application/atom+xml
      > -or-
      > GET /tutorials/hacking101
      > Accept: text/html
      >
      > Now, in the HTML document, the author wish to provide a link to lead
      > readers to ATOM document.
      >
      > <html>
      > <head>
      > <link rel="alternative" type="application/atom+xml" title="ATOM
      > verson" href="/tutorials/hacking101">
      > </head>
      > <body>
      >
      > <a href="/tutorials/hacking101" type="application/atom+xml">ATOM
      > version of Hacking101</a> is available now!
      >
      > </body>
      > </html>
      >
      > The same url is used here (without trailing .ext).
      > When the user click the link, a web browser should aware the "type"
      > attribute and send a specific request as follow, to receive ATOM
      > document:
      >
      > GET /tutorials/hacking101
      > Accept:application/atom+xml
      >
      > But, does this action consistent in major web browsers?

      No. I don't think <a type="..."/> does what you think. It's only a
      hint, it's not a request.

      HTTP/1.1 suggests that a resource should not be tied to a
      representation, that it should be possible to have differeing forms of
      the representation.

      But this inherantly means one form of representation cannot refer to
      another without specific meta markup.

      That's what <link rel="alternate"/> is for. It's meta markup for
      representation relationships.

      If you want to tell the user about alternative representations in a
      safe HTML-y kind of way what you could do is have some JavaScript in
      the page (or a greasemonkey script) to parse the DOM and present the
      <link rel="alternate"/> forms with associated XmlHttpRequest logic to
      get the alternate form and make it current (or pop it up in the new
      window).


      But you can't do it with just browser config. It just doesn't work
      like that.


      Nic
    • toydi
      ... that s the problem..when RESTie meets The Browser. :P Although REST encourage URL not to be representation-specific (ex. trailing .html, .xml, .atom etc)
      Message 2 of 27 , Jul 19, 2005
      • 0 Attachment
        > No. I don't think <a type="..."/> does what you think. It's only a
        > hint, it's not a request.

        that's the problem..when RESTie meets The Browser. :P

        Although REST encourage URL not to be representation-specific
        (ex. trailing .html, .xml, .atom etc)

        however, when using browsers, without the trailing .ext URL,
        end-users cannot retrieve a representation by simply click on
        the link.

        <a href="/tutorials/hacking101.atom" >click to download.</a> (this works)

        <a href="/tutorials/hacking101" type="application/atom+xml">click to
        download.</a> (this wont)


        > That's what <link rel="alternate"/> is for. It's meta markup for
        > representation relationships.

        so in this case, /tutorials/hacking101.atom and /tutorial/hacking101
        should be treated
        as two different resources.

        And, we still can relate both with a <link rel="alternate> element in
        both documents.

        Then, this will not violate the REST, and yet provide accessibility
        for browser users.

        Of course, othe clients still should be able to request an ATOM
        representation from
        /tutorials/hacking101 by inserting a correct Accept tag.

        "hacking101.atom" is providing an extra accessibilty solution.


        > If you want to tell the user about alternative representations in a
        > safe HTML-y kind of way what you could do is have some JavaScript in
        > the page (or a greasemonkey script) to parse the DOM and present the
        > <link rel="alternate"/> forms with associated XmlHttpRequest logic to
        > get the alternate form and make it current (or pop it up in the new
        > window).
        XmlHttpRequest is just a wonderful object. It brings REST to browser world. ;)

        --
        -toydi-
      • Nic Ferrier
        ... I think you re overestimating the role of the browser in REST. REST is a set of strictures for the creation of webservices. It s primary competitor is
        Message 3 of 27 , Jul 19, 2005
        • 0 Attachment
          toydi <iamstupidiot@...> writes:

          >> No. I don't think <a type="..."/> does what you think. It's only a
          >> hint, it's not a request.
          >
          > that's the problem..when RESTie meets The Browser. :P

          I think you're overestimating the role of the browser in REST.

          REST is a set of strictures for the creation of webservices. It's
          primary competitor is SOAP. You don't write browser webapps with
          SOAP. You shouldn't feel constrained to write browser webapps with
          REST.

          REST is a useful guiding principle when desigined webapps but you're
          talking here about quite an esoteric thing in terms of webapps.

          I'm still not sure *why* you want to do this.


          >> That's what <link rel="alternate"/> is for. It's meta markup for
          >> representation relationships.
          >
          > so in this case, /tutorials/hacking101.atom and /tutorial/hacking101
          > should be treated
          > as two different resources.

          No... Because using different extensions would break a really anal
          view of REST (though personally, I've always looked at REST as more
          guidelines, you know?)

          I was suggesting using the <link rel="alternate"/> to establish the
          relationship between entitys with the same name but different
          representations.

          When you say this:

          <link rel="alternate" type="text/xml" href="/someplace"/>

          it tells you that the current document has an alternate representation
          at /someplace and the alternate document is of type text/xml.

          Most browsers don't do anything with this stuff... but you can code
          script to do things with it; pseudo JS:

          var link_element = getFirstAlternateLinkElement(document);
          var accept_hdr = "Accepts: " + link_element.type;
          XmlHttpRequest(link_element.href, accept_hdr, some_handler_func);

          That - if you clear up the syntax errors and implement everything that
          isn't impelemented - will retrieve an alternate representation of the
          current document without requriring you to have different names for
          the representations.


          Nic
        • Lucas Gonze
          ... The requirement for extensions is because of the interface with MIME helper apps. They re invoked by the browser with a single command-line parameter, the
          Message 4 of 27 , Jul 19, 2005
          • 0 Attachment
            toydi wrote:

            > > No. I don't think <a type="..."/> does what you think. It's only a
            > > hint, it's not a request.
            >
            >that's the problem..when RESTie meets The Browser. :P
            >
            >Although REST encourage URL not to be representation-specific
            >(ex. trailing .html, .xml, .atom etc)
            >
            >however, when using browsers, without the trailing .ext URL,
            >end-users cannot retrieve a representation by simply click on
            >the link
            >
            >
            The requirement for extensions is because of the interface with MIME
            helper apps. They're invoked by the browser with a single command-line
            parameter, the name of the temp file created for the download, and if
            they expect to handle more than one mime type they have to guess the
            file type. Some handlers do content sniffing (e.g. WMP) but most (e.g.
            Quicktime) rely on the extension.

            The only exception to that rule that I know of is ASX -- Mozilla treats
            a .asx URL differently than a non .asx URL, even if they have the same
            MIME type.

            - Lucas
          • Walden Mathews
            what is it about this thread that makes me suspect that it is actually spam? ... From: toydi To: Dimitri Glazkov
            Message 5 of 27 , Jul 19, 2005
            • 0 Attachment
              what is it about this thread that makes me suspect
              that it is actually spam?


              ----- Original Message -----
              From: "toydi" <iamstupidiot@...>
              To: "Dimitri Glazkov" <dimitri.glazkov@...>
              Cc: "Nic Ferrier" <nferrier@...>; "Rest List"
              <rest-discuss@yahoogroups.com>
              Sent: Monday, July 18, 2005 11:06 PM
              Subject: Re: [rest-discuss] Switching content type


              :> Could you post the details of your research here? I am very interested
              : > in this topic, as well.
              :
              : i'm doing a study on practical REST implementation in current web
              application.
              : IMHO, it might be a good start to introduce REST to public, by showing
              examples
              : of RESTful web applications (ex. restful weblog, CMS, forums etc),
              : which people familiar with.
              :
              : currently, i'm developing a PHP5 framework. It shall be modeled as OO
              : as possible, so that the framework model is portable to different OO
              : languages (ex. java).
              : The framework will supply a core engine to handle request, and userful
              : libraries to help developers to build RESTful web application easier.
              :
              : also, i'm seeking info about behaviors of current web infrastructure
              : upon RESTful app (ex. caching issues, browsers limitations), and
              : hopefully work out some solutions..
              :
              : hopeful you could share your experiences. :)
              :
              : > > but when designing web applications for both machines and humans,
              : > > current browsers is limiting end users from altering Accept tag in
              : > > HTTP headers.
              : >
              : > The browsers don't, but the XMLHttpRequest allows that just fine. I
              : > have a test case working here, where if an XHTML document is requested
              : > by a browser, the "text/html" content type is returned (fallback
              : > scenario for IE compatibility), but the same document requested by
              : > XMLHttpRequest with setRequestHeader("Accept", "application/xml")
              : > returns "application/xml" type. This allows parsing and manipulate the
              : > XHTML document as an XML DOM tree.
              :
              : it's interesting. are you using server scripts to check the Accept tag? or
              using
              : web server configuration (ex Apache's httpd.conf)?
              :
              : (i just realize there are more to concern when using server side
              : scripting to implement REST :| more details in :
              : http://groups.yahoo.com/group/rest-discuss/message/5149)
              :
              :
              : > It works, except IE caches the content type and does not allow the
              : > same document to exist as both xml and html within the session -- it's
              : > either one or the other.
              :
              : which means IE browser cache doesnt really concern about Content-Type
              : while caching?
              :
              : if fetching several document versions (different content-type or
              : language) using one same URL? For example, web server returns
              : different documents based on Accept tag.
              :
              : > GET /test/document
              : Accept: text/html
              : < HTML representation
              :
              : > GET /test/document
              : Accept: application/xhtml+xml
              : < XHTML representation
              :
              : > GET /test/document
              : Accept: application/atom+xml
              : < ATOM represetation
              :
              : how the browser cache will behave? and what about cache proxies?
              :
              : --
              : -toydi-
              :
              :
              :
              : Yahoo! Groups Links
              :
              :
              :
              :
              :
              :
              :
              : __________ NOD32 1.1173 (20050719) Information __________
              :
              : This message was checked by NOD32 antivirus system.
              : http://www.eset.com
              :
              :
            • Justin T. Sampson
              ... AAAaaarrrggghhh!! Any time your understanding of REST disagrees with your understanding of how the Web works, one or the other is *wrong*. REST is all
              Message 6 of 27 , Jul 19, 2005
              • 0 Attachment
                Nic Ferrier wrote:

                > toydi <iamstupidiot@...> writes:
                >
                > > > No. I don't think <a type="..."/> does what you think. It's
                > > > only a hint, it's not a request.
                > >
                > > that's the problem..when RESTie meets The Browser. :P
                >
                > I think you're overestimating the role of the browser in REST.
                >
                > REST is a set of strictures for the creation of webservices.
                > It's primary competitor is SOAP. You don't write browser webapps
                > with SOAP. You shouldn't feel constrained to write browser
                > webapps with REST.

                AAAaaarrrggghhh!!

                Any time your understanding of REST disagrees with your
                understanding of how the Web works, one or the other is *wrong*.

                REST is all about Web servers, Web browsers, Web proxies, Web
                sites, Web apps, and, only incidentally, Web services. A Web app
                is just a dynamic Web site, and a Web service is just a
                machine-readable Web app.

                Want to offer the user multiple representations? Go ahead and give
                each one a different extension. Why not? It helps the user
                understand what they're getting, besides the fact that it just
                works. Even if you're using <link rel=alternate>, you need to give
                a distinct URI for each representation so the browser can actually
                grab what the user asked for.

                Content negotiation is not for parameterizing a request in order
                to get specific versions of a document. Parameters intended to
                explicitly request a specific thing should go in the URI (for
                example, as a ".xxx" extension on the "filename"). If I desire a
                PDF rendition of my bank statement, that's a specific resource
                that I care about. I don't want HTML; that would be a different
                resource. If, on the other hand, I merely desire my bank
                statement, and I don't care what specific file format it comes in,
                I'm happy if my browser and the server conspire to give me the
                best representation that they both support, which is exactly what
                content negotiation is all about.

                Cheers,
                Justin :)
              • Nic Ferrier
                ... I m not sure if you mean this as a personal insult or as a general statement. If it s a personal insult then fine. But if it s a general statement then
                Message 7 of 27 , Jul 20, 2005
                • 0 Attachment
                  "Justin T. Sampson" <justin@...> writes:

                  > Nic Ferrier wrote:
                  >
                  >> toydi <iamstupidiot@...> writes:
                  >>
                  >> > > No. I don't think <a type="..."/> does what you think. It's
                  >> > > only a hint, it's not a request.
                  >> >
                  >> > that's the problem..when RESTie meets The Browser. :P
                  >>
                  >> I think you're overestimating the role of the browser in REST.
                  >>
                  >> REST is a set of strictures for the creation of webservices.
                  >> It's primary competitor is SOAP. You don't write browser webapps
                  >> with SOAP. You shouldn't feel constrained to write browser
                  >> webapps with REST.
                  >
                  > AAAaaarrrggghhh!!
                  >
                  > Any time your understanding of REST disagrees with your
                  > understanding of how the Web works, one or the other is *wrong*.

                  I'm not sure if you mean this as a personal insult or as a general
                  statement.

                  If it's a personal insult then fine.


                  But if it's a general statement then it's not quite true is it?

                  For example, the web works with cookies quite a lot. But cookies are
                  not RESTfull.


                  > Want to offer the user multiple representations? Go ahead and give
                  > each one a different extension. Why not?

                  Because cool-uris don't change:


                  > It helps the user understand what they're getting, besides the fact
                  > that it just works. Even if you're using <link rel=alternate>, you
                  > need to give a distinct URI for each representation so the browser
                  > can actually grab what the user asked for.

                  Err... no. As discussed you can use the Accept header to identify
                  which resource you want.


                  > Content negotiation is not for parameterizing a request in order
                  > to get specific versions of a document. Parameters intended to
                  > explicitly request a specific thing should go in the URI (for
                  > example, as a ".xxx" extension on the "filename"). If I desire a
                  > PDF rendition of my bank statement, that's a specific resource
                  > that I care about. I don't want HTML; that would be a different
                  > resource. If, on the other hand, I merely desire my bank
                  > statement, and I don't care what specific file format it comes in,
                  > I'm happy if my browser and the server conspire to give me the
                  > best representation that they both support, which is exactly what
                  > content negotiation is all about.

                  I don't understand your argument - surely the situation is exactly the
                  opposite? Content negotiation is for selecting the representation of
                  the document that the client wants to see. URIs should identify
                  resources, NOT representations of resources.

                  As long as they really are the same resource.


                  Nic
                • Nic Ferrier
                  I m very tired so I forgot to add the url for cool uris don t change: http://www.w3.org/Provider/Style/URI.html Nic
                  Message 8 of 27 , Jul 20, 2005
                  • 0 Attachment
                    I'm very tired so I forgot to add the url for cool uris don't change:

                    http://www.w3.org/Provider/Style/URI.html


                    Nic
                  • Justin T. Sampson
                    ... Hi Nic! I didn t intend it as personal, but I realize it sounded that way and I apologize. It s a general frustration with many recurring discussions by
                    Message 9 of 27 , Jul 20, 2005
                    • 0 Attachment
                      Nic Ferrier wrote:

                      > "Justin T. Sampson" <justin@...> writes:
                      >
                      > > > [...]
                      > >
                      > > AAAaaarrrggghhh!!
                      > >
                      > > Any time your understanding of REST disagrees with your
                      > > understanding of how the Web works, one or the other is
                      > > *wrong*.
                      >
                      > I'm not sure if you mean this as a personal insult or as a
                      > general statement.
                      >
                      > If it's a personal insult then fine.

                      Hi Nic!

                      I didn't intend it as personal, but I realize it sounded that way
                      and I apologize. It's a general frustration with many recurring
                      discussions by many people here and elsewhere about REST as if
                      it's primarily an alternative to SOAP, when in fact its origins
                      had very little to do with what are now called Web services. REST
                      is an analysis of why the Web architecture works as well as it
                      does, and a tool to understand what does and doesn't work well on
                      the Web.

                      > But if it's a general statement then it's not quite true is it?
                      >
                      > For example, the web works with cookies quite a lot. But cookies
                      > are not RESTfull.

                      Cookies are a great example because they actually cause a lot of
                      problems for the operation of caching proxies, among other issues.
                      Understanding REST helps us to understand and predict such
                      problems for Web sites, Web apps, and Web services alike. Cookies
                      do violate REST, and they do cause problems on the real Web.

                      So a clearer way to state my original point is that Web apps and
                      Web services are equal in the eyes of REST. When I'm designing a
                      Web service, I think about how I'd do it as a Web app as well, and
                      consider what REST tells me about both. And REST needs at least as
                      much advocacy in the Web app world as in the Web service world at
                      this point.

                      > > Want to offer the user multiple representations? Go ahead and
                      > > give each one a different extension. Why not?
                      >
                      > Because cool-uris don't change:

                      So the cool URI for each version doesn't change. That doesn't mean
                      you can't have multiple URIs for multiple renditions of a file, if
                      those different renditions are meaningful to a user such that a
                      user would actually want to request one or the other (or several
                      different versions).

                      > > It helps the user understand what they're getting, besides the
                      > > fact that it just works. Even if you're using <link
                      > > rel=alternate>, you need to give a distinct URI for each
                      > > representation so the browser can actually grab what the user
                      > > asked for.
                      >
                      > Err... no. As discussed you can use the Accept header to
                      > identify which resource you want.

                      Not really -- Accept doesn't guarantee (and certainly doesn't
                      *identify*) getting a particular representation, it expresses
                      preferences and abilities to allow negotiation of an appropriate
                      content type between the client and the server.

                      > > Content negotiation is not for parameterizing a request in
                      > > order to get specific versions of a document. Parameters
                      > > intended to explicitly request a specific thing should go in
                      > > the URI (for example, as a ".xxx" extension on the
                      > > "filename"). If I desire a PDF rendition of my bank statement,
                      > > that's a specific resource that I care about. I don't want
                      > > HTML; that would be a different resource. If, on the other
                      > > hand, I merely desire my bank statement, and I don't care what
                      > > specific file format it comes in, I'm happy if my browser and
                      > > the server conspire to give me the best representation that
                      > > they both support, which is exactly what content negotiation
                      > > is all about.
                      >
                      > I don't understand your argument - surely the situation is
                      > exactly the opposite? Content negotiation is for selecting the
                      > representation of the document that the client wants to see.
                      > URIs should identify resources, NOT representations of
                      > resources.
                      >
                      > As long as they really are the same resource.

                      Resources are concepts. If I have separate concepts of "bank
                      statement in PDF" and "bank statement in HTML", then two separate
                      URIs (one ending in .pdf and one ending in .html) make the most
                      conceptual sense. If I browse to the HTML rendition and then click
                      a link to download the PDF rendition, those are two separate
                      resources as far as I'm concerned. It's not content negotiation,
                      because my browser fully supports both. PDF and HTML are actually
                      different enough in user experience that I would never expect
                      content negotiation between them; content negotiation might
                      however choose between PNG and GIF for an image rendered inline,
                      because I have no conceptual distinction between them in that
                      case.

                      Bottom line is this: REST really says very little about what URIs
                      should look like. REST does say to use URIs to identify whatever
                      needs identifying, and to use hypertext to make those URIs known.
                      Anything beyond that is aesthetics. It's good to make URIs
                      meaningful to whoever might look at them, and to leave out
                      anything not relevant to what is being identified (most especially
                      implementation details like cgi, php, or jsp, but perhaps also
                      filename extensions *if that's not what's being identified
                      conceptually*), but they are opaque to the REST architectural
                      style itself.

                      Cheers,
                      Justin
                    • Nic Ferrier
                      ... I do agree with you. My point is that human facing webapps (as opposed to machine facing ones which we might call web services) sometimes have to be a
                      Message 10 of 27 , Jul 20, 2005
                      • 0 Attachment
                        "Justin T. Sampson" <justin@...> writes:

                        > So a clearer way to state my original point is that Web apps and
                        > Web services are equal in the eyes of REST. When I'm designing a
                        > Web service, I think about how I'd do it as a Web app as well, and
                        > consider what REST tells me about both. And REST needs at least as
                        > much advocacy in the Web app world as in the Web service world at
                        > this point.

                        I do agree with you. My point is that human facing webapps (as opposed
                        to machine facing ones which we might call web services) sometimes
                        have to be a little more flexible than REST allows (because the owners
                        of the webapp demand it).

                        Web services on the other hand are rarely subject to the sort of
                        technical incompetent hand waving that stops REST being used in
                        webapps.

                        A world built on webservices is all we really need, because then we
                        can write our own webapps.


                        >> > Want to offer the user multiple representations? Go ahead and
                        >> > give each one a different extension. Why not?
                        >>
                        >> Because cool-uris don't change:
                        >
                        > So the cool URI for each version doesn't change. That doesn't mean
                        > you can't have multiple URIs for multiple renditions of a file, if
                        > those different renditions are meaningful to a user such that a
                        > user would actually want to request one or the other (or several
                        > different versions).

                        You're talking about versions and I'm talking about representations of
                        one version.

                        I often deal in situations where I have two or more XML
                        representations and an HTML representation of the same data. Cool URIs
                        Don't Change suggests that you shouldn't try and put the
                        representation into the resource name because that ties you to a
                        format.

                        If I have a resource:

                        http://www.tapsellferrier.co.uk/things/others/specialthing-1

                        then why should I insist to clients that they look at that as HTML? or
                        XML? or PDF? or an image?

                        It should be whatever they want within the bounds of what I can
                        supply.


                        >> Err... no. As discussed you can use the Accept header to
                        >> identify which resource you want.
                        >
                        > Not really -- Accept doesn't guarantee (and certainly doesn't
                        > *identify*) getting a particular representation, it expresses
                        > preferences and abilities to allow negotiation of an appropriate
                        > content type between the client and the server.

                        Yes, Really. If the server can't supply what you want then it is
                        supposed to say 406. Right now most webapp don't do this very often
                        but as REST advocates we all know about spec non-compliance right?


                        > Resources are concepts. If I have separate concepts of "bank
                        > statement in PDF" and "bank statement in HTML", then two separate
                        > URIs (one ending in .pdf and one ending in .html) make the most
                        > conceptual sense.

                        I disagree because cool URIs don't change.

                        If you have separate concepts of "bank statement in PDF" and "bank
                        statement in HTML" then I think you're quite unusual. I think of my
                        bank statement as my bank statement and I think most people do.

                        Resources should not be tied to representations. The reason for this
                        is that the resource that identifies my bank statement should always
                        be the same. When I'm seventy (if I still have the same bank account
                        which is pretty unlikely I have to say) I'd expect my bank statement
                        URI to be the same.

                        More importantly if I have a resource to identify me then I don't want
                        to tie that to one or other document format.


                        > Bottom line is this: REST really says very little about what URIs
                        > should look like. REST does say to use URIs to identify whatever
                        > needs identifying, and to use hypertext to make those URIs known.
                        > Anything beyond that is aesthetics. It's good to make URIs
                        > meaningful to whoever might look at them, and to leave out
                        > anything not relevant to what is being identified (most especially
                        > implementation details like cgi, php, or jsp, but perhaps also
                        > filename extensions *if that's not what's being identified
                        > conceptually*), but they are opaque to the REST architectural
                        > style itself.

                        Ok. So it comes down to whether you accept that Cool URIs Don't
                        Change is part of REST. I can't remember if there's anything in Roy's
                        original paper about this. But since this stuff is quite clear in the
                        HTTP spec I believe that cool URIs don't change. /8->


                        Nic
                      • Roy T. Fielding
                        ... No, there are three resources. One is your generic bank statement. Second is your bank statement in PDF. Third is your bank statement in HTML. Three
                        Message 11 of 27 , Jul 20, 2005
                        • 0 Attachment
                          On Jul 20, 2005, at 5:18 AM, Nic Ferrier wrote:

                          >> Resources are concepts. If I have separate concepts of "bank
                          >> statement in PDF" and "bank statement in HTML", then two separate
                          >> URIs (one ending in .pdf and one ending in .html) make the most
                          >> conceptual sense.
                          >
                          > I disagree because cool URIs don't change.
                          >
                          > If you have separate concepts of "bank statement in PDF" and "bank
                          > statement in HTML" then I think you're quite unusual. I think of my
                          > bank statement as my bank statement and I think most people do.

                          No, there are three resources. One is your generic bank statement.
                          Second is your bank statement in PDF. Third is your bank statement
                          in HTML. Three distinct resources calls for three distinct URIs,
                          even if one of them is just a negotiation point for the rest.

                          > Resources should not be tied to representations. The reason for this
                          > is that the resource that identifies my bank statement should always
                          > be the same. When I'm seventy (if I still have the same bank account
                          > which is pretty unlikely I have to say) I'd expect my bank statement
                          > URI to be the same.

                          That is true for some interactions, but not all. Authoring, for
                          example, should always be performed on a specific URI that is
                          dependent on the format, since that allows you to author many
                          different representations for the more generic URI at the same
                          time without having to rely on server gymnastics to understand
                          what resource is being authored.

                          > Ok. So it comes down to whether you accept that Cool URIs Don't
                          > Change is part of REST. I can't remember if there's anything in Roy's
                          > original paper about this. But since this stuff is quite clear in the
                          > HTTP spec I believe that cool URIs don't change. /8->

                          Those are orthogonal issues. The fact that you have one URI that
                          is generic does not in any way limit the number of less generic
                          URIs that are also used and available within an application.
                          All URIs are important.

                          REST is designed so that URI references don't need to change,
                          which is the principle behind Tim's "cool URIs don't change"
                          comments. That is the final bit of

                          This abstract definition of a resource enables key features
                          of the Web architecture. First, it provides generality by
                          encompassing many sources of information without artificially
                          distinguishing them by type or implementation. Second, it
                          allows late binding of the reference to a representation,
                          enabling content negotiation to take place based on
                          characteristics of the request. Finally, it allows an author
                          to reference the concept rather than some singular
                          representation of that concept, thus removing the need to
                          change all existing links whenever the representation
                          changes (assuming the author used the right identifier).

                          Using the right identifier requires that identifiers be available
                          for everything one might want to identify, including each individual
                          resource that makes up the value set of some "cool URI" resource.

                          ....Roy
                        • Nic Ferrier
                          ... When you PUT the server could use the content-type to decide what representation is to be edited. I don t understand why you class that as gymnastics.
                          Message 12 of 27 , Jul 20, 2005
                          • 0 Attachment
                            "Roy T. Fielding" <fielding@...> writes:

                            > On Jul 20, 2005, at 5:18 AM, Nic Ferrier wrote:
                            >
                            >> Resources should not be tied to representations. The reason for this
                            >> is that the resource that identifies my bank statement should always
                            >> be the same. When I'm seventy (if I still have the same bank account
                            >> which is pretty unlikely I have to say) I'd expect my bank statement
                            >> URI to be the same.
                            >
                            > That is true for some interactions, but not all. Authoring, for
                            > example, should always be performed on a specific URI that is
                            > dependent on the format, since that allows you to author many
                            > different representations for the more generic URI at the same
                            > time without having to rely on server gymnastics to understand
                            > what resource is being authored.

                            When you PUT the server could use the content-type to decide what
                            representation is to be edited.

                            I don't understand why you class that as gymnastics.


                            Doing it this way gives the server the chance to say: sorry, that
                            representation isn't supported by me (if the user submitted something
                            un-indexable perhaps).


                            Of course, I'd be pretty annoyed if I'd just typed war and peace into
                            a text box and the server said that.


                            Nic
                          • Roy T. Fielding
                            ... Because I ve written HTTP clients and HTTP servers. If the server assumes that every content type is a variant of a single resource instead of a
                            Message 13 of 27 , Jul 20, 2005
                            • 0 Attachment
                              On Jul 20, 2005, at 7:25 AM, Nic Ferrier wrote:

                              > When you PUT the server could use the content-type to decide what
                              > representation is to be edited.
                              >
                              > I don't understand why you class that as gymnastics.

                              Because I've written HTTP clients and HTTP servers.

                              If the server assumes that every content type is a variant of
                              a single resource instead of a representation, then clients are
                              unable to replace an HTML representation with an XML representation.

                              In order for the client to present an accurate user interface
                              for authoring a negotiated resource, it would have to know all of
                              the potential media types that might be representations for a given
                              resource. Not just the ones that are valid now, but all of those
                              that might ever be valid.

                              In contrast, if you design the system such that negotiated URIs
                              cannot be authored (they redirect using 300 instead), then the
                              client doesn't need to know in advance how the resource is
                              implemented. If the server receives an XML replacement for a
                              negotiated URI, it can redirect to the media-specific URI for XML.
                              If the server receives the same for a non-negotiated URI, it can
                              simply replace the current representation and respond with 200.

                              That way, the client gets informed of the URIs for the other
                              specific resources that it might need to author or delete.

                              Note that there is yet another resource in effect here, and
                              that is the one that tells the server how to map each resource
                              to a set of representations. That can be authored as well
                              if we give it a URI of its own.

                              > Doing it this way gives the server the chance to say: sorry, that
                              > representation isn't supported by me (if the user submitted something
                              > un-indexable perhaps).

                              Why would anyone want such a feature?

                              > Of course, I'd be pretty annoyed if I'd just typed war and peace into
                              > a text box and the server said that.

                              I'd be pretty annoyed by the text box. ;-) HTML forms are not a
                              good editing environment and HTTP certainly isn't limited to them.
                              MS Word writes directly to web folders which is just another
                              HTTP client library (with bugs).

                              ....Roy
                            • Nic Ferrier
                              ... Yes. I know. And you wrote the specs. It s certainly difficult arguing with you because of that. But hey! I m cantankerous! I have written clients and
                              Message 14 of 27 , Jul 20, 2005
                              • 0 Attachment
                                "Roy T. Fielding" <fielding@...> writes:

                                > On Jul 20, 2005, at 7:25 AM, Nic Ferrier wrote:
                                >
                                >> When you PUT the server could use the content-type to decide what
                                >> representation is to be edited.
                                >>
                                >> I don't understand why you class that as gymnastics.
                                >
                                > Because I've written HTTP clients and HTTP servers.

                                Yes. I know. And you wrote the specs. It's certainly difficult arguing
                                with you because of that. But hey! I'm cantankerous!


                                I have written clients and servers as well (though I'm sure not as
                                many as you) but I've never felt that content negotiation was onerous.


                                > If the server assumes that every content type is a variant of
                                > a single resource instead of a representation, then clients are
                                > unable to replace an HTML representation with an XML representation.

                                How so? text/html and text/xml (or application/xml or
                                application/xml+rss or whatever).

                                I agree that it's not possible to replace one text/xml with another
                                text/xml even though they might be different representations (eg: src
                                document and fo). I can honestly say I've never run into that
                                particular problem. Mostly I find that one (maybe 2) authorial formats
                                are used within a particular system.


                                > In order for the client to present an accurate user interface
                                > for authoring a negotiated resource, it would have to know all of
                                > the potential media types that might be representations for a given
                                > resource. Not just the ones that are valid now, but all of those
                                > that might ever be valid.

                                I certainly wasn't suggesting that.

                                While I was making that suggestion I was imagining a large CMS with
                                many authors. Something on the scale of wikipedia (but that's not
                                unique at all, I've worked on similar sized things for clients).

                                In such a system using a PUT system with content negotiation might be
                                useful. People have different editors that produce different content
                                types and a content-neg system could ease the use of that.

                                Maybe I could write an article on honey bees (which are a current
                                interest of mine) in HTML and PUT it to /cms/apismellifera.

                                A collegue might spot some mistakes and opens the resource in Word. He
                                changes the mistakes, saves a local copy (in .doc) and PUTs the
                                resource back to the server under the same URL: /cms/apismellifera.

                                The server doesn't accept Word DOC format so it sends a 406 and my
                                colleague tells Word to save it as HTML this time. Then it works.

                                Weeks later we upgrade the CMS so that it accepts Word DOC format as a
                                representation for resources and my colleague goes through exactly the
                                same process as before with another mistake. This time he can PUT the
                                document in Word DOC format.


                                In the meantime whenever someone GETs the resource /cms/apismellifera
                                they do the same content neg. Mostly people with browsers do
                                text/html, text/xml, *.*. People with other editors might highly
                                prioritize native formats which the server would deliver if it had
                                them or could generate them.


                                > That way, the client gets informed of the URIs for the other
                                > specific resources that it might need to author or delete.

                                Ah. I think I see what you're getting at.

                                I have been making a presumption based on my personal practice. My
                                personal practice is to not allow a representation unless it can be
                                arrived at by conversion from another representation.

                                In the system I describe above it would have to be a decision for the
                                CMS administrators whether to allow representations that would result
                                in lossy conversions to the other representations to be added.


                                Given representations with no conversion I do see what you're getting
                                at.

                                And clearly being able to convert is not a requirement of the specs.


                                >> Of course, I'd be pretty annoyed if I'd just typed war and peace into
                                >> a text box and the server said that.
                                >
                                > I'd be pretty annoyed by the text box. ;-) HTML forms are not a
                                > good editing environment and HTTP certainly isn't limited to them.
                                > MS Word writes directly to web folders which is just another
                                > HTTP client library (with bugs).

                                Yeah. I knew that. I was just trying to be funny.

                                And it's not that funny either because still with all these tools how
                                do we update the wikipedia page on Apis Mellifera?



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