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

Re: [rest-discuss] Switching content type

Expand Messages
  • 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 1 of 27 , Jul 19, 2005
      > 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 2 of 27 , Jul 19, 2005
        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 3 of 27 , Jul 19, 2005
          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 4 of 27 , Jul 19, 2005
            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 5 of 27 , Jul 19, 2005
              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 6 of 27 , Jul 20, 2005
                "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 7 of 27 , Jul 20, 2005
                  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 8 of 27 , Jul 20, 2005
                    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 9 of 27 , Jul 20, 2005
                      "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 10 of 27 , Jul 20, 2005
                        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 11 of 27 , Jul 20, 2005
                          "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 12 of 27 , Jul 20, 2005
                            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 13 of 27 , Jul 20, 2005
                              "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.