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

HTTP State Transitions

Expand Messages
  • Mike Kelly
    Are state transitions in HTTP simply the URI/Verb combination, or the entire of the message? I prefer the latter - perhaps if browsers took this approach;
    Message 1 of 25 , Jul 22, 2009
    • 0 Attachment
      Are state transitions in HTTP simply the URI/Verb combination, or the
      entire of the message?

      I prefer the latter - perhaps if browsers took this approach; serving
      multiple representations from one URI by conneg could work without
      breaking bookmarks and 'page' refreshes?

      - Mike
    • Mike Kelly
      Is a state transition adequately defined by: GET /resource or is it more appropriate to include the entire of the message? i.e.: GET /resource Accept:
      Message 2 of 25 , Jul 22, 2009
      • 0 Attachment
        Is a state transition adequately defined by:

        GET /resource

        or is it more appropriate to include the entire of the message? i.e.:

        GET /resource
        Accept: application/pdf
        Accept-Language: en-us
        .... etc

        If browsers treated each state as the full HTTP message, bookmarks and
        page refreshes would not 'break'.

        As it stands; if a browser refreshed or bookmarked the latter state, the
        Accept header would revert back to default (text/html, etc..) because
        the only part of the state transition stored is the URI/Verb combination.

        - Mike


        Dhananjay Nene wrote:
        > Not sure if I am the only one .. but couldn't really understand the
        > question. Maybe you could describe the question by stating an example
        > of the choices ?
      • Sebastien Lambla
        The problem comes from this: conneg served on the same URI should be used when the variation between the multiple representations is not important or
        Message 3 of 25 , Jul 22, 2009
        • 0 Attachment
          The problem comes from this: conneg served on the same URI should be used
          when the variation between the multiple representations is not important or
          substantial.

          If it's important enough that the returned representation be constant over
          time for you to send a link to that specific representation, that
          representation ought to be promoted to its own URI as a separate resource.

          So while conneg used for formatting dates may well be a valid use and does
          not necessitate a separate resource, I'm pretty sure a pdf / html or a jpg /
          gif will become quite problematic.

          > -----Original Message-----
          > From: rest-discuss@yahoogroups.com [mailto:rest-
          > discuss@yahoogroups.com] On Behalf Of Mike Kelly
          > Sent: 22 July 2009 14:10
          > To: Dhananjay Nene; Rest List
          > Subject: Re: [rest-discuss] HTTP State Transitions
          >
          > Is a state transition adequately defined by:
          >
          > GET /resource
          >
          > or is it more appropriate to include the entire of the message? i.e.:
          >
          > GET /resource
          > Accept: application/pdf
          > Accept-Language: en-us
          > .... etc
          >
          > If browsers treated each state as the full HTTP message, bookmarks and
          > page refreshes would not 'break'.
          >
          > As it stands; if a browser refreshed or bookmarked the latter state,
          > the
          > Accept header would revert back to default (text/html, etc..) because
          > the only part of the state transition stored is the URI/Verb
          > combination.
          >
          > - Mike
          >
          >
          > Dhananjay Nene wrote:
          > > Not sure if I am the only one .. but couldn't really understand the
          > > question. Maybe you could describe the question by stating an example
          > > of the choices ?
          >
          >
          >
          > ------------------------------------
          >
          > Yahoo! Groups Links
          >
          >
          >
        • António Mota
          But Accept: application/pdf has to do with the representation of the state of the resource, not to the state of the resource.
          Message 4 of 25 , Jul 22, 2009
          • 0 Attachment
            But

            Accept: application/pdf

            has to do with the "representation" of the state of the resource, not to
            the state of the resource.



            Mike Kelly wrote:
            >
            >
            > Is a state transition adequately defined by:
            >
            > GET /resource
            >
            > or is it more appropriate to include the entire of the message? i.e.:
            >
            > GET /resource
            > Accept: application/pdf
            > Accept-Language: en-us
            > .... etc
            >
            > If browsers treated each state as the full HTTP message, bookmarks and
            > page refreshes would not 'break'.
            >
            > As it stands; if a browser refreshed or bookmarked the latter state, the
            > Accept header would revert back to default (text/html, etc..) because
            > the only part of the state transition stored is the URI/Verb combination.
            >
            > - Mike
            >
            > Dhananjay Nene wrote:
            > > Not sure if I am the only one .. but couldn't really understand the
            > > question. Maybe you could describe the question by stating an example
            > > of the choices ?
            >
            >
          • Mike Kelly
            Hmm.. how about html/rss/atom/json then? If you get sent a link to /resource and don t want HTML - don t open it with a browser! :) Those kinds of problems
            Message 5 of 25 , Jul 22, 2009
            • 0 Attachment
              Hmm.. how about html/rss/atom/json then?

              If you get sent a link to /resource and don't want HTML - don't open it
              with a browser! :)

              Those kinds of problems could be solved with something equivalent to an
              'Open With..' menu, which could makes an OPTIONS request to the URI and
              list installed HTTP clients that accept any of the available
              Content-Type's listed.

              The distinction between representations and resources in your suggested
              approach seems pretty blurred (assuming the ends of URIs are opaque, of
              course!).

              - Mike


              Sebastien Lambla wrote:
              > The problem comes from this: conneg served on the same URI should be used
              > when the variation between the multiple representations is not important or
              > substantial.
              >
              > If it's important enough that the returned representation be constant over
              > time for you to send a link to that specific representation, that
              > representation ought to be promoted to its own URI as a separate resource.
              >
              > So while conneg used for formatting dates may well be a valid use and does
              > not necessitate a separate resource, I'm pretty sure a pdf / html or a jpg /
              > gif will become quite problematic.
              >
              >
              >> -----Original Message-----
              >> From: rest-discuss@yahoogroups.com [mailto:rest-
              >> discuss@yahoogroups.com] On Behalf Of Mike Kelly
              >> Sent: 22 July 2009 14:10
              >> To: Dhananjay Nene; Rest List
              >> Subject: Re: [rest-discuss] HTTP State Transitions
              >>
              >> Is a state transition adequately defined by:
              >>
              >> GET /resource
              >>
              >> or is it more appropriate to include the entire of the message? i.e.:
              >>
              >> GET /resource
              >> Accept: application/pdf
              >> Accept-Language: en-us
              >> .... etc
              >>
              >> If browsers treated each state as the full HTTP message, bookmarks and
              >> page refreshes would not 'break'.
              >>
              >> As it stands; if a browser refreshed or bookmarked the latter state,
              >> the
              >> Accept header would revert back to default (text/html, etc..) because
              >> the only part of the state transition stored is the URI/Verb
              >> combination.
              >>
              >> - Mike
              >>
              >>
              >> Dhananjay Nene wrote:
              >>
              >>> Not sure if I am the only one .. but couldn't really understand the
              >>> question. Maybe you could describe the question by stating an example
              >>> of the choices ?
              >>>
              >>
              >> ------------------------------------
              >>
              >> Yahoo! Groups Links
              >>
              >>
              >>
              >
              >
              >
            • Mike Kelly
              I was referring to application state, rather than resource state
              Message 6 of 25 , Jul 22, 2009
              • 0 Attachment
                I was referring to application state, rather than resource state

                António Mota wrote:
                > But
                >
                > Accept: application/pdf
                >
                > has to do with the "representation" of the state of the resource, not to
                > the state of the resource.
                >
                >
                >
                > Mike Kelly wrote:
                >
                >>
                >>
                >> Is a state transition adequately defined by:
                >>
                >> GET /resource
                >>
                >> or is it more appropriate to include the entire of the message? i.e.:
                >>
                >> GET /resource
                >> Accept: application/pdf
                >> Accept-Language: en-us
                >> .... etc
                >>
                >> If browsers treated each state as the full HTTP message, bookmarks and
                >> page refreshes would not 'break'.
                >>
                >> As it stands; if a browser refreshed or bookmarked the latter state, the
                >> Accept header would revert back to default (text/html, etc..) because
                >> the only part of the state transition stored is the URI/Verb combination.
                >>
                >> - Mike
                >>
                >> Dhananjay Nene wrote:
                >>
                >>> Not sure if I am the only one .. but couldn't really understand the
                >>> question. Maybe you could describe the question by stating an example
                >>> of the choices ?
                >>>
                >>
                >
                >
                >
                > ------------------------------------
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
              • Sebastien Lambla
                Well, let s put it this way. Provided the xml or json representation of a resource are semantically equivalent (aka contain the same state), I see no reason
                Message 7 of 25 , Jul 22, 2009
                • 0 Attachment
                  Well, let's put it this way. Provided the xml or json representation of a
                  resource are semantically equivalent (aka contain the same state), I see no
                  reason not to use conneg on those. The expectation of an automated user
                  agent is not the same as the expectation of a user, and as such I don't see
                  much benefit in pushing for separate URIs for different serializations of
                  the same resource state.

                  As for choosing multiple media types that are available, provided you
                  promote the ones that should be linkable independently (and my definition of
                  what is desirably independent is based on user expectation), we already have
                  this, with a 300 response to a simple GET on a generic URI. Agent-driven
                  conneg is perfectly acceptable but requires separate URIs for each notable
                  representation.

                  As for the difference between resource and representation, it can be blurry,
                  as a resource may have multiple representations, and a representation may be
                  a resource itself (aka have its own URI).

                  The awww:resource is anything important enough to have a URI. When
                  dereferencing such URI, the response may be no representation (in which case
                  it may be an http URI denoting a thing, for example as used in rdf), one
                  representation (there is one representation sent to the client, based on
                  Conneg or current state of the resource), the resource could be the
                  representation (in which case it's an IR, the resource is the
                  representation, in the sense that all properties of the resource can be
                  transferred in the representation), or a list of representations through a
                  300 (and then one cannot decipher the kind of resource we're talking about,
                  but can access individual representations promoted as resources through the
                  uris linked in the response).

                  It's not blurred as such, it's the current landscape of what resources are
                  and what URI denotes on the web.

                  Seb

                  > -----Original Message-----
                  > From: Mike Kelly [mailto:mike@...]
                  > Sent: 22 July 2009 14:41
                  > To: Sebastien Lambla
                  > Cc: 'Dhananjay Nene'; 'Rest List'
                  > Subject: Re: [rest-discuss] HTTP State Transitions
                  >
                  > Hmm.. how about html/rss/atom/json then?
                  >
                  > If you get sent a link to /resource and don't want HTML - don't open it
                  > with a browser! :)
                  >
                  > Those kinds of problems could be solved with something equivalent to an
                  > 'Open With..' menu, which could makes an OPTIONS request to the URI and
                  > list installed HTTP clients that accept any of the available
                  > Content-Type's listed.
                  >
                  > The distinction between representations and resources in your suggested
                  > approach seems pretty blurred (assuming the ends of URIs are opaque, of
                  > course!).
                  >
                  > - Mike
                  >
                  >
                  > Sebastien Lambla wrote:
                  > > The problem comes from this: conneg served on the same URI should be
                  > used
                  > > when the variation between the multiple representations is not
                  > important or
                  > > substantial.
                  > >
                  > > If it's important enough that the returned representation be constant
                  > over
                  > > time for you to send a link to that specific representation, that
                  > > representation ought to be promoted to its own URI as a separate
                  > resource.
                  > >
                  > > So while conneg used for formatting dates may well be a valid use and
                  > does
                  > > not necessitate a separate resource, I'm pretty sure a pdf / html or
                  > a jpg /
                  > > gif will become quite problematic.
                  > >
                  > >
                  > >> -----Original Message-----
                  > >> From: rest-discuss@yahoogroups.com [mailto:rest-
                  > >> discuss@yahoogroups.com] On Behalf Of Mike Kelly
                  > >> Sent: 22 July 2009 14:10
                  > >> To: Dhananjay Nene; Rest List
                  > >> Subject: Re: [rest-discuss] HTTP State Transitions
                  > >>
                  > >> Is a state transition adequately defined by:
                  > >>
                  > >> GET /resource
                  > >>
                  > >> or is it more appropriate to include the entire of the message?
                  > i.e.:
                  > >>
                  > >> GET /resource
                  > >> Accept: application/pdf
                  > >> Accept-Language: en-us
                  > >> .... etc
                  > >>
                  > >> If browsers treated each state as the full HTTP message, bookmarks
                  > and
                  > >> page refreshes would not 'break'.
                  > >>
                  > >> As it stands; if a browser refreshed or bookmarked the latter state,
                  > >> the
                  > >> Accept header would revert back to default (text/html, etc..)
                  > because
                  > >> the only part of the state transition stored is the URI/Verb
                  > >> combination.
                  > >>
                  > >> - Mike
                  > >>
                  > >>
                  > >> Dhananjay Nene wrote:
                  > >>
                  > >>> Not sure if I am the only one .. but couldn't really understand the
                  > >>> question. Maybe you could describe the question by stating an
                  > example
                  > >>> of the choices ?
                  > >>>
                  > >>
                  > >> ------------------------------------
                  > >>
                  > >> Yahoo! Groups Links
                  > >>
                  > >>
                  > >>
                  > >
                  > >
                  > >
                • António Mota
                  I don t understand then. Application state resides on the client, so you want to bookmark that? I thought bookmarks point to resources, not to something that
                  Message 8 of 25 , Jul 22, 2009
                  • 0 Attachment
                    I don't understand then. Application state resides on the client, so you
                    want to bookmark that? I thought bookmarks point to resources, not to
                    something that resides on the client.

                    Mike Kelly wrote:
                    > I was referring to application state, rather than resource state
                    >
                    > António Mota wrote:
                    >> But
                    >>
                    >> Accept: application/pdf
                    >>
                    >> has to do with the "representation" of the state of the resource, not
                    >> to the state of the resource.
                    >>
                    >>
                    >>
                    >> Mike Kelly wrote:
                    >>
                    >>>
                    >>>
                    >>> Is a state transition adequately defined by:
                    >>>
                    >>> GET /resource
                    >>>
                    >>> or is it more appropriate to include the entire of the message? i.e.:
                    >>>
                    >>> GET /resource
                    >>> Accept: application/pdf
                    >>> Accept-Language: en-us
                    >>> .... etc
                    >>>
                    >>> If browsers treated each state as the full HTTP message, bookmarks and
                    >>> page refreshes would not 'break'.
                    >>>
                    >>> As it stands; if a browser refreshed or bookmarked the latter state,
                    >>> the
                    >>> Accept header would revert back to default (text/html, etc..) because
                    >>> the only part of the state transition stored is the URI/Verb
                    >>> combination.
                    >>>
                    >>> - Mike
                    >>>
                    >>> Dhananjay Nene wrote:
                    >>>
                    >>>> Not sure if I am the only one .. but couldn't really understand the
                    >>>> question. Maybe you could describe the question by stating an example
                    >>>> of the choices ?
                    >>>>
                    >>>
                    >>
                    >>
                    >>
                    >> ------------------------------------
                    >>
                    >> Yahoo! Groups Links
                    >>
                    >>
                    >>
                    >>
                    >
                  • Mike Kelly
                    ... We ve discussed this already elsewhere - I understand why you might feel the need to give a representation a URI. As you know, I am of the opinion that the
                    Message 9 of 25 , Jul 22, 2009
                    • 0 Attachment
                      Sebastien Lambla wrote:
                      > Well, let's put it this way. Provided the xml or json representation of a
                      > resource are semantically equivalent (aka contain the same state), I see no
                      > reason not to use conneg on those. The expectation of an automated user
                      > agent is not the same as the expectation of a user, and as such I don't see
                      > much benefit in pushing for separate URIs for different serializations of
                      > the same resource state.
                      >
                      > As for choosing multiple media types that are available, provided you
                      > promote the ones that should be linkable independently (and my definition of
                      > what is desirably independent is based on user expectation), we already have
                      > this, with a 300 response to a simple GET on a generic URI. Agent-driven
                      > conneg is perfectly acceptable but requires separate URIs for each notable
                      > representation.
                      >
                      > As for the difference between resource and representation, it can be blurry,
                      > as a resource may have multiple representations, and a representation may be
                      > a resource itself (aka have its own URI).
                      >
                      > The awww:resource is anything important enough to have a URI. When
                      > dereferencing such URI, the response may be no representation (in which case
                      > it may be an http URI denoting a thing, for example as used in rdf), one
                      > representation (there is one representation sent to the client, based on
                      > Conneg or current state of the resource), the resource could be the
                      > representation (in which case it's an IR, the resource is the
                      > representation, in the sense that all properties of the resource can be
                      > transferred in the representation), or a list of representations through a
                      > 300 (and then one cannot decipher the kind of resource we're talking about,
                      > but can access individual representations promoted as resources through the
                      > uris linked in the response).
                      >
                      > It's not blurred as such, it's the current landscape of what resources are
                      > and what URI denotes on the web.
                      >

                      We've discussed this already elsewhere - I understand why you might feel
                      the need to give a representation a URI.

                      As you know, I am of the opinion that the costs of taking that approach
                      (complications in cache-invalidation/other intermediary mechanisms,
                      degraded uniformity, convoluted messages with Link headers) outweigh the
                      benefit (being able to exchange a plain-text hyperlink directly to a
                      specific representation).

                      We're missing the point a bit here; the purpose of this thread was to
                      establish whether or not a state transition is defined by the whole
                      message or just the URI/Verb, if the conclusion is the latter - then
                      there is a far stronger case for URI 'conneg'. If it's the former, the
                      case is not necessarily stronger for HTTP conneg - but parties such as
                      browser vendors and WHATWG should be encouraged to provide the
                      mechanisms necessary to pursue this alternative, non-conflicting,
                      approach to content negotiation.

                      - Mike
                    • Sebastien Lambla
                      ... As far as my understanding of your question goes, you re trying to define an identifier of a representation as URI of resource, plus verb, plus whatever
                      Message 10 of 25 , Jul 22, 2009
                      • 0 Attachment
                        > We're missing the point a bit here; the purpose of this thread was to
                        > establish whether or not a state transition is defined by the whole
                        > message or just the URI/Verb, if the conclusion is the latter - then
                        > there is a far stronger case for URI 'conneg'. If it's the former, the
                        > case is not necessarily stronger for HTTP conneg - but parties such as
                        > browser vendors and WHATWG should be encouraged to provide the
                        > mechanisms necessary to pursue this alternative, non-conflicting,
                        > approach to content negotiation.

                        As far as my understanding of your question goes, you're trying to define an
                        identifier of a representation as URI of resource, plus verb, plus whatever
                        message headers impact on the selection of the representation.

                        I make the argument that one shouldn't try to define such an identifier. The
                        identifier of a resource is enough, and if it is the case that you want to
                        identify a specific representation, then making that representation a
                        resource ought to be enough.

                        The state transition is the result of dereferencing such identifier, and is
                        dependent on the state of the application. As such, it is of course
                        dependent on the current state the client has, if any, and the current state
                        the server holds.

                        I just don't see what the conneg of an entity body has to do with the state
                        transition, I see them at different levels in the http layers, and I
                        certainly have modelled it that way in my framework.

                        Maybe I just don't get what problem you're trying to solve here.

                        Seb
                      • Mike Kelly
                        ... I could be wrong - but I was under the impression that a hyperlink can be more than just a URI.
                        Message 11 of 25 , Jul 22, 2009
                        • 0 Attachment
                          Sebastien Lambla wrote:
                          >> We're missing the point a bit here; the purpose of this thread was to
                          >> establish whether or not a state transition is defined by the whole
                          >> message or just the URI/Verb, if the conclusion is the latter - then
                          >> there is a far stronger case for URI 'conneg'. If it's the former, the
                          >> case is not necessarily stronger for HTTP conneg - but parties such as
                          >> browser vendors and WHATWG should be encouraged to provide the
                          >> mechanisms necessary to pursue this alternative, non-conflicting,
                          >> approach to content negotiation.
                          >>
                          >
                          > As far as my understanding of your question goes, you're trying to define an
                          > identifier of a representation as URI of resource, plus verb, plus whatever
                          > message headers impact on the selection of the representation.
                          >
                          > I make the argument that one shouldn't try to define such an identifier. The
                          > identifier of a resource is enough, and if it is the case that you want to
                          > identify a specific representation, then making that representation a
                          > resource ought to be enough.
                          >
                          > The state transition is the result of dereferencing such identifier, and is
                          > dependent on the state of the application. As such, it is of course
                          > dependent on the current state the client has, if any, and the current state
                          > the server holds.
                          >
                          > I just don't see what the conneg of an entity body has to do with the state
                          > transition, I see them at different levels in the http layers, and I
                          > certainly have modelled it that way in my framework.
                          >
                          > Maybe I just don't get what problem you're trying to solve here.
                          >

                          I could be wrong - but I was under the impression that a hyperlink can
                          be more than just a URI.
                        • Dhananjay Nene
                          ... Can we treat this as two different questions ? a) How is a state adequately defined : A URI such as GET /resource adequately defines the application state
                          Message 12 of 25 , Jul 22, 2009
                          • 0 Attachment
                            On Wed, Jul 22, 2009 at 6:39 PM, Mike Kelly <mike@...> wrote:
                            Is a state transition adequately defined by:

                            GET /resource

                            or is it more appropriate to include the entire of the message? i.e.:

                            GET /resource
                            Accept: application/pdf
                            Accept-Language: en-us
                            .... etc

                            If browsers treated each state as the full HTTP message, bookmarks and page refreshes would not 'break'.

                            As it stands; if a browser refreshed or bookmarked the latter state, the Accept header would revert back to default (text/html, etc..) because the only part of the state transition stored is the URI/Verb combination.

                            - Mike



                            Dhananjay Nene wrote:
                            Not sure if I am the only one .. but couldn't really understand the question. Maybe you could describe the question by stating an example of the choices ?

                            Mike,

                            Can we treat this as two different questions ?

                            a) How is a state adequately defined : A URI such as GET /resource adequately defines the application state  The http headers / metadata have no implication on the application state. Whether you choose to view a document in a PDF or HTML or perhaps even as a PNG has no bearing on the application. The application state is always the same for the same URI irrespective of the content type.

                            b) How is a bookmark adequately defined ? This is really a question for the author of a browser to answer. If we had a browser which say allowed you to also describe the accept headers before making the URI, then let us for a moment suggest that such a browser the bookmark perhaps could contain the accept header. However we don't have such browsers (I haven't seen one at least). But it is likely that programmatic clients may want to choose to store such URIs for say resuming later. Such a browser is again unlikely to 'break' if it is able to accept and parse various content types with equal capability or works with only one content type which it always specifically requests. However it could break if in a particular situation it has requested a particular resource with a non default accept headers and that is specifically needed to resume further. In such a situation, perhaps the bookmark could store the accept header. But even in this case the accept headers imo are not an attribute of the application state - they are an application of the conversation state (though I am open to be challenged since I myself am not so terribly convinced about it).

                            Dhananjay

                            --
                            --------------------------------------------------------
                            blog: http://blog.dhananjaynene.com
                            twitter: http://twitter.com/dnene
                          • Sebastien Lambla
                            ... As i feared, you ve lost me. I d like to separate at this stage the bookmark, which is defined as the identifier of a resource (in the case of HTTP, a
                            Message 13 of 25 , Jul 22, 2009
                            • 0 Attachment
                              > I could be wrong - but I was under the impression that a hyperlink can
                              > be more than just a URI.

                              As i feared, you've lost me.

                              I'd like to separate at this stage the bookmark, which is defined as the identifier of a resource (in the case of HTTP, a URI), and the hypermedia control, which is the dereferencing of such URI using an adequate verb and whatever message headers and client state the user agent see fit in adding.

                              As such, I think your original question deals with what identifies a bookmark. It's my belief that the state transition is depending on the client state, and as such is a different context than the simple dereferencing of the identifier of a resource.

                              My previous comments still hold true, in both cases.


                              Seb


                              Windows Live Messenger: Happy 10-Year Anniversary—get free winks and emoticons. Get Them Now
                            • Mike Kelly
                              ... Not an identifier , as such; just the full state transition (including control data) required to select a given representation. ... I understand that a
                              Message 14 of 25 , Jul 23, 2009
                              • 0 Attachment
                                Sebastien Lambla wrote:
                                >> We're missing the point a bit here; the purpose of this thread was to
                                >> establish whether or not a state transition is defined by the whole
                                >> message or just the URI/Verb, if the conclusion is the latter - then
                                >> there is a far stronger case for URI 'conneg'. If it's the former, the
                                >> case is not necessarily stronger for HTTP conneg - but parties such as
                                >> browser vendors and WHATWG should be encouraged to provide the
                                >> mechanisms necessary to pursue this alternative, non-conflicting,
                                >> approach to content negotiation.
                                >>
                                >
                                > As far as my understanding of your question goes, you're trying to define an
                                > identifier of a representation as URI of resource, plus verb, plus whatever
                                > message headers impact on the selection of the representation.
                                >
                                >

                                Not an 'identifier', as such; just the full state transition (including
                                control data) required to select a given representation.

                                > I make the argument that one shouldn't try to define such an identifier. The
                                > identifier of a resource is enough, and if it is the case that you want to
                                > identify a specific representation, then making that representation a
                                > resource ought to be enough.
                                >

                                I understand that a representation can be 'made a resource', although
                                the phrase 'treated as if it were' would be more appropriate.

                                It's slightly confusing when you state that an identifier to a resource
                                is 'enough', and then immediately contradict this position by
                                entertaining 'the case that you want to identify a specific representation'.

                                So it's hard, from that, to make sense of whether or not treating a
                                representation as a resource 'ought to be enough'. This is particularly
                                apparent given, as I mentioned before, the only significant benefit from
                                doing this is that you get *plain text* hyperlinks to your
                                representations - the value of this is questionable if an identifier to
                                a resource is 'enough' in the first place.

                                > The state transition is the result of dereferencing such identifier, and is
                                > dependent on the state of the application. As such, it is of course
                                > dependent on the current state the client has, if any, and the current state
                                > the server holds.
                                >

                                If it is possible for a hyperlink to include control data, then a
                                hypermedia driven state transition is more than simply dereferencing an
                                href URI.

                                > I just don't see what the conneg of an entity body has to do with the state
                                > transition, I see them at different levels in the http layers, and I
                                > certainly have modelled it that way in my framework.
                                >

                                *Representational* State Transfer (?)


                                - Mike
                              • Mike Kelly
                                ... Hi Dhananjay, Why would application state always be the same for all representations of a resource? ... That is, essentially, what I was suggesting ... I
                                Message 15 of 25 , Jul 27, 2009
                                • 0 Attachment
                                  Dhananjay Nene wrote:
                                  >
                                  >
                                  > On Wed, Jul 22, 2009 at 6:39 PM, Mike Kelly <mike@...
                                  > <mailto:mike@...>> wrote:
                                  >
                                  > Is a state transition adequately defined by:
                                  >
                                  > GET /resource
                                  >
                                  > or is it more appropriate to include the entire of the message? i.e.:
                                  >
                                  > GET /resource
                                  > Accept: application/pdf
                                  > Accept-Language: en-us
                                  > .... etc
                                  >
                                  > If browsers treated each state as the full HTTP message, bookmarks
                                  > and page refreshes would not 'break'.
                                  >
                                  > As it stands; if a browser refreshed or bookmarked the latter
                                  > state, the Accept header would revert back to default (text/html,
                                  > etc..) because the only part of the state transition stored is the
                                  > URI/Verb combination.
                                  >
                                  > - Mike
                                  >
                                  >
                                  >
                                  > Dhananjay Nene wrote:
                                  >
                                  > Not sure if I am the only one .. but couldn't really
                                  > understand the question. Maybe you could describe the question
                                  > by stating an example of the choices ?
                                  >
                                  >
                                  > Mike,
                                  >
                                  > Can we treat this as two different questions ?
                                  >
                                  > a) How is a state adequately defined : A URI such as GET /resource
                                  > adequately defines the application state The http headers / metadata
                                  > have no implication on the application state. Whether you choose to
                                  > view a document in a PDF or HTML or perhaps even as a PNG has no
                                  > bearing on the application. The application state is always the same
                                  > for the same URI irrespective of the content type.
                                  >

                                  Hi Dhananjay,

                                  Why would application state always be the same for all representations
                                  of a resource?

                                  > b) How is a bookmark adequately defined ? This is really a question
                                  > for the author of a browser to answer. If we had a browser which say
                                  > allowed you to also describe the accept headers before making the URI,
                                  > then let us for a moment suggest that such a browser the bookmark
                                  > perhaps could contain the accept header. However we don't have such
                                  > browsers (I haven't seen one at least). But it is likely that
                                  > programmatic clients may want to choose to store such URIs for say
                                  > resuming later. Such a browser is again unlikely to 'break' if it is
                                  > able to accept and parse various content types with equal capability
                                  > or works with only one content type which it always specifically
                                  > requests. However it could break if in a particular situation it has
                                  > requested a particular resource with a non default accept headers and
                                  > that is specifically needed to resume further. In such a situation,
                                  > perhaps the bookmark could store the accept header.

                                  That is, essentially, what I was suggesting

                                  > But even in this case the accept headers imo are not an attribute of
                                  > the application state - they are an application of the conversation
                                  > state (though I am open to be challenged since I myself am not so
                                  > terribly convinced about it).

                                  I don't know if I understand what you mean by 'application of the
                                  conversation state' - but there is no room for a state between
                                  application and resource, given communication in RESTful systems is
                                  (supposed to be) stateless.

                                  Cheers,
                                  Mike
                                • Dhananjay Nene
                                  ... An application state reflects where the user is in the overall workflow supported / managed by the application. It is therefore not dependent upon the
                                  Message 16 of 25 , Jul 27, 2009
                                  • 0 Attachment
                                    On Mon, Jul 27, 2009 at 2:29 PM, Mike Kelly <mike@...> wrote:
                                    Dhananjay Nene wrote:



                                    On Wed, Jul 22, 2009 at 6:39 PM, Mike Kelly <mike@... <mailto:mike@...>> wrote:

                                       Is a state transition adequately defined by:

                                       GET /resource

                                       or is it more appropriate to include the entire of the message? i.e.:

                                       GET /resource
                                       Accept: application/pdf
                                       Accept-Language: en-us
                                       .... etc

                                       If browsers treated each state as the full HTTP message, bookmarks
                                       and page refreshes would not 'break'.

                                       As it stands; if a browser refreshed or bookmarked the latter
                                       state, the Accept header would revert back to default (text/html,
                                       etc..) because the only part of the state transition stored is the
                                       URI/Verb combination.

                                       - Mike



                                       Dhananjay Nene wrote:

                                           Not sure if I am the only one .. but couldn't really
                                           understand the question. Maybe you could describe the question
                                           by stating an example of the choices ?


                                    Mike,

                                    Can we treat this as two different questions ?

                                    a) How is a state adequately defined : A URI such as GET /resource adequately defines the application state  The http headers / metadata have no implication on the application state. Whether you choose to view a document in a PDF or HTML or perhaps even as a PNG has no bearing on the application. The application state is always the same for the same URI irrespective of the content type.


                                    Hi Dhananjay,

                                    Why would application state always be the same for all representations of a resource?

                                    An application state reflects where the user is in the overall workflow supported / managed by the application. It is therefore not dependent upon the representation. eg. if I am being shown an itinerary for my approval prior to a final booking, I am in the state of reviewing the itinerary - irrespective of whether the itinerary was being rendered as XHTML, JSON, XML, PDF or PNG.
                                     


                                    b) How is a bookmark adequately defined ? This is really a question for the author of a browser to answer. If we had a browser which say allowed you to also describe the accept headers before making the URI, then let us for a moment suggest that such a browser the bookmark perhaps could contain the accept header. However we don't have such browsers (I haven't seen one at least). But it is likely that programmatic clients may want to choose to store such URIs for say resuming later. Such a browser is again unlikely to 'break' if it is able to accept and parse various content types with equal capability or works with only one content type which it always specifically requests. However it could break if in a particular situation it has requested a particular resource with a non default accept headers and that is specifically needed to resume further. In such a situation, perhaps the bookmark could store the accept header.

                                    That is, essentially, what I was suggesting

                                    Yes, thats what I had assumed you were referring to - I was on the other hand attempting to separate the notion of the bookmark and the application state - ie. they are not one and the same.


                                    But even in this case the accept headers imo are not an attribute of the application state - they are an application of the conversation state (though I am open to be challenged since I myself am not so terribly convinced about it).

                                    I don't know if I understand what you mean by 'application of the conversation state' - but there is no room for a state between application and resource, given communication in RESTful systems is (supposed to be) stateless.

                                    Sorry, made a mistake there - should've stated " the accept headers imo are not an attribute of the application state - they are an attribute of the conversation state". Though reading it again I feel a little lame. I should've been more specific and should've said "the accept headers imo are not an attribute of the application state - they are merely the influencers of a representation as a part of a given conversation"



                                    Cheers,
                                    Mike



                                    --
                                    --------------------------------------------------------
                                    blog: http://blog.dhananjaynene.com
                                    twitter: http://twitter.com/dnene
                                  • Mike Kelly
                                    ... A bookmark is an application state a user would like to return to. Given that application state must be driven by hypermedia - a bookmark can be considered
                                    Message 17 of 25 , Jul 27, 2009
                                    • 0 Attachment
                                      António Mota wrote:
                                      > I don't understand then. Application state resides on the client, so
                                      > you want to bookmark that? I thought bookmarks point to resources, not
                                      > to something that resides on the client.
                                      >

                                      A bookmark is an application state a user would like to return to. Given
                                      that application state must be driven by hypermedia - a bookmark can be
                                      considered a client side store representing a particular hyperlink (i.e.
                                      state transition).


                                      So my question is around whether or not it is feasible for a hypermedia
                                      format to include control data in its hyperlinks. In HTML one example of
                                      this could be:

                                      <a href="/report" accept="application/pdf">Report (PDF)</a>
                                      <a href="/report" accept="application/msexcel">Report (Excel)</a>
                                      <a href="/report" accept="image/png">Report (PNG)</a>
                                      <a href="/report">Report (Default HTML)</a>

                                      I'm not sure adding this data to bookmarks would change the 'direction'
                                      they point, but it would obviously allow for a bookmark to point to a
                                      specific representation rather than just a resource - thus addressing
                                      the primary argument against using HTTP conneg.

                                      Cheers,
                                      Mike
                                    • Mike Kelly
                                      ... I m not sure if I understand the distinction you make between application and resource state ... If a bookmark is not a stored reference to a given
                                      Message 18 of 25 , Jul 27, 2009
                                      • 0 Attachment
                                        Dhananjay Nene wrote:
                                        >
                                        >
                                        > On Mon, Jul 27, 2009 at 2:29 PM, Mike Kelly <mike@...
                                        > <mailto:mike@...>> wrote:
                                        >
                                        >
                                        > Hi Dhananjay,
                                        >
                                        > Why would application state always be the same for all
                                        > representations of a resource?
                                        >
                                        >
                                        > An application state reflects where the user is in the overall
                                        > workflow supported / managed by the application. It is therefore not
                                        > dependent upon the representation. eg. if I am being shown an
                                        > itinerary for my approval prior to a final booking, I am in the state
                                        > of reviewing the itinerary - irrespective of whether the itinerary was
                                        > being rendered as XHTML, JSON, XML, PDF or PNG.

                                        I'm not sure if I understand the distinction you make between
                                        application and resource state

                                        >
                                        >
                                        >
                                        >
                                        > b) How is a bookmark adequately defined ? This is really a
                                        > question for the author of a browser to answer. If we had a
                                        > browser which say allowed you to also describe the accept
                                        > headers before making the URI, then let us for a moment
                                        > suggest that such a browser the bookmark perhaps could contain
                                        > the accept header. However we don't have such browsers (I
                                        > haven't seen one at least). But it is likely that programmatic
                                        > clients may want to choose to store such URIs for say resuming
                                        > later. Such a browser is again unlikely to 'break' if it is
                                        > able to accept and parse various content types with equal
                                        > capability or works with only one content type which it always
                                        > specifically requests. However it could break if in a
                                        > particular situation it has requested a particular resource
                                        > with a non default accept headers and that is specifically
                                        > needed to resume further. In such a situation, perhaps the
                                        > bookmark could store the accept header.
                                        >
                                        >
                                        > That is, essentially, what I was suggesting
                                        >
                                        >
                                        > Yes, thats what I had assumed you were referring to - I was on the
                                        > other hand attempting to separate the notion of the bookmark and the
                                        > application state - ie. they are not one and the same.

                                        If a bookmark is not a stored reference to a given application state,
                                        what is it?

                                        >
                                        >
                                        > But even in this case the accept headers imo are not an
                                        > attribute of the application state - they are an application
                                        > of the conversation state (though I am open to be challenged
                                        > since I myself am not so terribly convinced about it).
                                        >
                                        >
                                        > I don't know if I understand what you mean by 'application of the
                                        > conversation state' - but there is no room for a state between
                                        > application and resource, given communication in RESTful systems
                                        > is (supposed to be) stateless.
                                        >
                                        >
                                        > Sorry, made a mistake there - should've stated " the accept headers
                                        > imo are not an attribute of the application state - they are an
                                        > _*attribute*_ of the conversation state". Though reading it again I
                                        > feel a little lame. I should've been more specific and should've said
                                        > "the accept headers imo are not an attribute of the application state
                                        > - they are merely the influencers of a representation as a part of a
                                        > given conversation"
                                        >

                                        If they are influencing the representation transfered, they are
                                        impacting on the application state. I can agree that there is no
                                        difference between the resource state, but that is desired behavior from
                                        negotiated representations of the same resource.

                                        - Mike
                                      • Dhananjay Nene
                                        Mike, ... XHTML / JSON formats are an attribute of the resource representation - they cannot be an attribute of the application state, since from an
                                        Message 19 of 25 , Jul 27, 2009
                                        • 0 Attachment
                                          Mike,

                                          On Mon, Jul 27, 2009 at 3:15 PM, Mike Kelly <mike@...> wrote:
                                          Dhananjay Nene wrote:



                                          On Mon, Jul 27, 2009 at 2:29 PM, Mike Kelly <mike@... <mailto:mike@...>> wrote:


                                             Hi Dhananjay,

                                             Why would application state always be the same for all
                                             representations of a resource?


                                          An application state reflects where the user is in the overall workflow supported / managed by the application. It is therefore not dependent upon the representation. eg. if I am being shown an itinerary for my approval prior to a final booking, I am in the state of reviewing the itinerary - irrespective of whether the itinerary was being rendered as XHTML, JSON, XML, PDF or PNG.

                                          I'm not sure if I understand the distinction you make between application and resource state
                                          XHTML / JSON formats are an attribute of the resource representation - they cannot be an attribute of the application state, since from an application perspective, the user is exactly at the same place in the overall workflow irrespective of the resource representation.


                                           


                                                 b) How is a bookmark adequately defined ? This is really a
                                                 question for the author of a browser to answer. If we had a
                                                 browser which say allowed you to also describe the accept
                                                 headers before making the URI, then let us for a moment
                                                 suggest that such a browser the bookmark perhaps could contain
                                                 the accept header. However we don't have such browsers (I
                                                 haven't seen one at least). But it is likely that programmatic
                                                 clients may want to choose to store such URIs for say resuming
                                                 later. Such a browser is again unlikely to 'break' if it is
                                                 able to accept and parse various content types with equal
                                                 capability or works with only one content type which it always
                                                 specifically requests. However it could break if in a
                                                 particular situation it has requested a particular resource
                                                 with a non default accept headers and that is specifically
                                                 needed to resume further. In such a situation, perhaps the
                                                 bookmark could store the accept header.


                                             That is, essentially, what I was suggesting


                                          Yes, thats what I had assumed you were referring to - I was on the other hand attempting to separate the notion of the bookmark and the application state - ie. they are not one and the same.

                                          If a bookmark is not a stored reference to a given application state, what is it?
                                          In this context it is a stored reference to an application state + a preferred format.




                                                 But even in this case the accept headers imo are not an
                                                 attribute of the application state - they are an application
                                                 of the conversation state (though I am open to be challenged
                                                 since I myself am not so terribly convinced about it).


                                             I don't know if I understand what you mean by 'application of the
                                             conversation state' - but there is no room for a state between
                                             application and resource, given communication in RESTful systems
                                             is (supposed to be) stateless.


                                          Sorry, made a mistake there - should've stated " the accept headers imo are not an attribute of the application state - they are an _*attribute*_ of the conversation state". Though reading it again I feel a little lame. I should've been more specific and should've said "the accept headers imo are not an attribute of the application state - they are merely the influencers of a representation as a part of a given conversation"


                                          If they are influencing the representation transfered, they are impacting on the application state. I can agree that there is no difference between the resource state, but that is desired behavior from negotiated representations of the same resource.

                                          I would just suggest the following hypothetical scenario. If I received a XHTML version of my itinerary and it had a link to obtain a PDF version, and then I click it - would it mean that the I would do a state transition from one state to another or would it be from a state to itself. I am arguing that both are same states ie. the transition is back to the same state, from what I presume you've been stating the user does a state transition to a different state. If I am correct in that assessment, then we differ in the essential understanding of application state and may have work to do to figure out which is the more appropriate interpretation.
                                           


                                          - Mike

                                          Dhananjay
                                        • Mike Kelly
                                          ... This seems to imply tight coupling between resource and application state. I can t agree that these are the same states from an application perspective
                                          Message 20 of 25 , Jul 27, 2009
                                          • 0 Attachment
                                            Dhananjay Nene wrote:
                                            >
                                            >
                                            > Mike,
                                            >
                                            > On Mon, Jul 27, 2009 at 3:15 PM, Mike Kelly <mike@...
                                            > <mailto:mike@...>> wrote:
                                            >
                                            > Dhananjay Nene wrote:
                                            >
                                            >
                                            >
                                            > On Mon, Jul 27, 2009 at 2:29 PM, Mike Kelly
                                            > <mike@... <mailto:mike@...>
                                            > <mailto:mike@... <mailto:mike@...>>> wrote:
                                            >
                                            >
                                            > Hi Dhananjay,
                                            >
                                            > Why would application state always be the same for all
                                            > representations of a resource?
                                            >
                                            >
                                            > An application state reflects where the user is in the overall
                                            > workflow supported / managed by the application. It is
                                            > therefore not dependent upon the representation. eg. if I am
                                            > being shown an itinerary for my approval prior to a final
                                            > booking, I am in the state of reviewing the itinerary -
                                            > irrespective of whether the itinerary was being rendered as
                                            > XHTML, JSON, XML, PDF or PNG.
                                            >
                                            >
                                            > I'm not sure if I understand the distinction you make between
                                            > application and resource state
                                            >
                                            > XHTML / JSON formats are an attribute of the resource representation -
                                            > they cannot be an attribute of the application state, since from an
                                            > application perspective, the user is exactly at the same place in the
                                            > overall workflow irrespective of the resource representation.

                                            This seems to imply tight coupling between resource and application
                                            state. I can't agree that these are the same states from an application
                                            perspective because they are clearly distinguished by control data in
                                            the HTTP message (Accept/Content-Type in this specific case).

                                            >
                                            >
                                            >
                                            >
                                            >
                                            > b) How is a bookmark adequately defined ? This is really a
                                            > question for the author of a browser to answer. If we had a
                                            > browser which say allowed you to also describe the accept
                                            > headers before making the URI, then let us for a moment
                                            > suggest that such a browser the bookmark perhaps could
                                            > contain
                                            > the accept header. However we don't have such browsers (I
                                            > haven't seen one at least). But it is likely that
                                            > programmatic
                                            > clients may want to choose to store such URIs for say
                                            > resuming
                                            > later. Such a browser is again unlikely to 'break' if it is
                                            > able to accept and parse various content types with equal
                                            > capability or works with only one content type which it
                                            > always
                                            > specifically requests. However it could break if in a
                                            > particular situation it has requested a particular resource
                                            > with a non default accept headers and that is specifically
                                            > needed to resume further. In such a situation, perhaps the
                                            > bookmark could store the accept header.
                                            >
                                            >
                                            > That is, essentially, what I was suggesting
                                            >
                                            >
                                            > Yes, thats what I had assumed you were referring to - I was on
                                            > the other hand attempting to separate the notion of the
                                            > bookmark and the application state - ie. they are not one and
                                            > the same.
                                            >
                                            >
                                            > If a bookmark is not a stored reference to a given application
                                            > state, what is it?
                                            >
                                            > In this context it is a stored reference to an application state + a
                                            > preferred format.

                                            The array of representations for a given resource are not application
                                            states in their own right?

                                            How would you model negotiating these formats in a state machine,
                                            without treating them as separate states?

                                            >
                                            >
                                            >
                                            >
                                            > But even in this case the accept headers imo are not an
                                            > attribute of the application state - they are an
                                            > application
                                            > of the conversation state (though I am open to be
                                            > challenged
                                            > since I myself am not so terribly convinced about it).
                                            >
                                            >
                                            > I don't know if I understand what you mean by 'application
                                            > of the
                                            > conversation state' - but there is no room for a state between
                                            > application and resource, given communication in RESTful
                                            > systems
                                            > is (supposed to be) stateless.
                                            >
                                            >
                                            > Sorry, made a mistake there - should've stated " the accept
                                            > headers imo are not an attribute of the application state -
                                            > they are an _*attribute*_ of the conversation state". Though
                                            > reading it again I feel a little lame. I should've been more
                                            > specific and should've said "the accept headers imo are not an
                                            > attribute of the application state - they are merely the
                                            > influencers of a representation as a part of a given conversation"
                                            >
                                            >
                                            > If they are influencing the representation transfered, they are
                                            > impacting on the application state. I can agree that there is no
                                            > difference between the resource state, but that is desired
                                            > behavior from negotiated representations of the same resource.
                                            >
                                            >
                                            > I would just suggest the following hypothetical scenario. If I
                                            > received a XHTML version of my itinerary and it had a link to obtain a
                                            > PDF version, and then I click it - would it mean that the I would do a
                                            > state transition from one state to another or would it be from a state
                                            > to itself.

                                            My understanding is that you are describing an application state
                                            transition, so I would say the former - as mentioned above this is
                                            clearly distinguished by the control data within each of the HTTP messages.


                                            Cheers,
                                            Mike
                                          • Dhananjay Nene
                                            My comments at the very end. ... I think it boils down to the fact whether one interprets a control-header and a representation format to influence an
                                            Message 21 of 25 , Jul 27, 2009
                                            • 0 Attachment
                                              My comments at the very end.

                                              On Mon, Jul 27, 2009 at 3:56 PM, Mike Kelly <mike@...> wrote:
                                              Dhananjay Nene wrote:


                                              Mike,


                                              On Mon, Jul 27, 2009 at 3:15 PM, Mike Kelly <mike@... <mailto:mike@...>> wrote:

                                                 Dhananjay Nene wrote:



                                                     On Mon, Jul 27, 2009 at 2:29 PM, Mike Kelly
                                                     <mike@... <mailto:mike@...>
                                                     <mailto:mike@... <mailto:mike@...>>> wrote:


                                                        Hi Dhananjay,

                                                        Why would application state always be the same for all
                                                        representations of a resource?


                                                     An application state reflects where the user is in the overall
                                                     workflow supported / managed by the application. It is
                                                     therefore not dependent upon the representation. eg. if I am
                                                     being shown an itinerary for my approval prior to a final
                                                     booking, I am in the state of reviewing the itinerary -
                                                     irrespective of whether the itinerary was being rendered as
                                                     XHTML, JSON, XML, PDF or PNG.


                                                 I'm not sure if I understand the distinction you make between
                                                 application and resource state

                                              XHTML / JSON formats are an attribute of the resource representation - they cannot be an attribute of the application state, since from an application perspective, the user is exactly at the same place in the overall workflow irrespective of the resource representation.

                                              This seems to imply tight coupling between resource and application state. I can't agree that these are the same states from an application perspective because they are clearly distinguished by control data in the HTTP message (Accept/Content-Type in this specific case).




                                                     

                                                            b) How is a bookmark adequately defined ? This is really a
                                                            question for the author of a browser to answer. If we had a
                                                            browser which say allowed you to also describe the accept
                                                            headers before making the URI, then let us for a moment
                                                            suggest that such a browser the bookmark perhaps could
                                                     contain
                                                            the accept header. However we don't have such browsers (I
                                                            haven't seen one at least). But it is likely that
                                                     programmatic
                                                            clients may want to choose to store such URIs for say
                                                     resuming
                                                            later. Such a browser is again unlikely to 'break' if it is
                                                            able to accept and parse various content types with equal
                                                            capability or works with only one content type which it
                                                     always
                                                            specifically requests. However it could break if in a
                                                            particular situation it has requested a particular resource
                                                            with a non default accept headers and that is specifically
                                                            needed to resume further. In such a situation, perhaps the
                                                            bookmark could store the accept header.


                                                        That is, essentially, what I was suggesting


                                                     Yes, thats what I had assumed you were referring to - I was on
                                                     the other hand attempting to separate the notion of the
                                                     bookmark and the application state - ie. they are not one and
                                                     the same.


                                                 If a bookmark is not a stored reference to a given application
                                                 state, what is it?

                                              In this context it is a stored reference to an application state + a preferred format.

                                              The array of representations for a given resource are not application states in their own right?

                                              How would you model negotiating these formats in a state machine, without treating them as separate states?






                                                            But even in this case the accept headers imo are not an
                                                            attribute of the application state - they are an
                                                     application
                                                            of the conversation state (though I am open to be
                                                     challenged
                                                            since I myself am not so terribly convinced about it).


                                                        I don't know if I understand what you mean by 'application
                                                     of the
                                                        conversation state' - but there is no room for a state between
                                                        application and resource, given communication in RESTful
                                                     systems
                                                        is (supposed to be) stateless.


                                                     Sorry, made a mistake there - should've stated " the accept
                                                     headers imo are not an attribute of the application state -
                                                     they are an _*attribute*_ of the conversation state". Though
                                                     reading it again I feel a little lame. I should've been more
                                                     specific and should've said "the accept headers imo are not an
                                                     attribute of the application state - they are merely the
                                                     influencers of a representation as a part of a given conversation"


                                                 If they are influencing the representation transfered, they are
                                                 impacting on the application state. I can agree that there is no
                                                 difference between the resource state, but that is desired
                                                 behavior from negotiated representations of the same resource.


                                              I would just suggest the following hypothetical scenario. If I received a XHTML version of my itinerary and it had a link to obtain a PDF version, and then I click it - would it mean that the I would do a state transition from one state to another or would it be from a state to itself.

                                              My understanding is that you are describing an application state transition, so I would say the former - as mentioned above this is clearly distinguished by the control data within each of the HTTP messages.


                                              Cheers,
                                              Mike


                                              I think it boils down to the fact whether one interprets a control-header and a representation format to influence an application state. I would only reiterate that since (and so long as) the representation does not influence where the user is in the overall workflow of the activity he is trying to achieve, the control headers or representation formats should not lead him to different application states (ie. so long as the URI is the same - its always the same application state).

                                              Some of the thoughts which might support this idea are :

                                              a) If different control headers mean different application states, then would it mean different users viewing the same page using different authentication headers are in a different application state ? Not so imo. Similarly if the response returns with different cache-control directives for the same page (eg. expiry time) does that imply different application states ?

                                              b) If one assumes a new (hypothetical) browser which does not understand HTML but works only with say PDF or Flash representations. Would now one assume that two users viewing the same page/URI  from two different browsers are looking at two different application states - again that does not sound appropriate to me.

                                              Having said that, I tried to search for an authoritative definition of what an Application State is including Fielding's thesis - however I could not find one.

                                              Does anyone in the group have any opinion on the matter (just to broadbase the conversation a little bit since I suspect myself and Mike have pushed it as far as we could perhaps carry it - that only being an assumption from my side) ?

                                              Dhananjay
                                            • Sebastien Lambla
                                              ... I m going back to what I stated before. If you care about identifying separate things, then they should be separate things. Conneged representations are
                                              Message 22 of 25 , Jul 27, 2009
                                              • 0 Attachment
                                                > > I'm not sure if I understand the distinction you make between
                                                > > application and resource state
                                                > >
                                                > > XHTML / JSON formats are an attribute of the resource representation
                                                > -
                                                > > they cannot be an attribute of the application state, since from an
                                                > > application perspective, the user is exactly at the same place in the
                                                > > overall workflow irrespective of the resource representation.
                                                >
                                                > This seems to imply tight coupling between resource and application
                                                > state. I can't agree that these are the same states from an application
                                                > perspective because they are clearly distinguished by control data in
                                                > the HTTP message (Accept/Content-Type in this specific case).

                                                I'm going back to what I stated before. If you care about identifying
                                                separate things, then they should be separate things. Conneged
                                                representations are *not* separate things because they share the same
                                                identifier.

                                                The application state is dependent on you navigating between things, not
                                                between representation of those things. If the representations have a
                                                meaningful distinction for the continuation of the state transitions, they
                                                should have identifiers. The identifiers we have are URIs to resources. If
                                                representations matter, then they should have their own identifiers, as such
                                                be promoted to resources themselves.

                                                Let's put it another way. If your application state depends not only on the
                                                existing identifier, but also in control state data, you have indeed created
                                                a new identifier, aka (URI+Method+Accept headers). I fail to see what this
                                                brings you, as opposed to simply identify representations as separate
                                                things?

                                                Client-driven conneg can only work for resource representations that do not
                                                differ enough to be meaningful to either the UA or the application state,
                                                hence why there is no provision for the extra data required to identify
                                                those.

                                                You say it yourself in the next paragraph:

                                                > > If a bookmark is not a stored reference to a given application
                                                > > state, what is it?
                                                > >
                                                > > In this context it is a stored reference to an application state + a
                                                > > preferred format.
                                                >
                                                > The array of representations for a given resource are not application
                                                > states in their own right?
                                                >
                                                > How would you model negotiating these formats in a state machine,
                                                > without treating them as separate states?

                                                If they have any meaningful distinction, then you represent them as
                                                separately identified resources. If they do not have meaningful distinction,
                                                then you don't.

                                                The required data for a state transition to occur is the current state of
                                                the application. In the case of a bookmark for a new client, there is no
                                                application state on the client.

                                                I'll also reply to your various questions from Thursday:

                                                > I understand that a representation can be 'made a resource', although
                                                > the phrase 'treated as if it were' would be more appropriate.

                                                I'm afraid we may just not be using the same terminology. I use the word
                                                'identifier' with the meaning of 'identifying a resource', and 'resource' as
                                                'the smallest unit i can deal with when doing state transitions in ReST' and
                                                as 'the thing / conceptual mapping / awww:resource identified by an
                                                identifier'. As such, I object strongly to the idea that there would be such
                                                a thing as 'treating a thing as a resource'. If it's important enough for me
                                                to interact with, and if it's identified, it's a resource.

                                                > It's slightly confusing when you state that an identifier to a resource
                                                > is 'enough', and then immediately contradict this position by
                                                > entertaining 'the case that you want to identify a specific
                                                > representation'.

                                                I apologize for introducing confusion. Let me attempt to reformulate better.

                                                If you want to interact with a thing, it has to be a resource. If you want
                                                to interact with two things distinctively, they are then fundamentally, by
                                                the ReST and HTTP requirement of resources having an identifier, two
                                                distinct resources. If however you interact with a single resource, that has
                                                multiple representations that you do not need to address specifically, then
                                                you may use conneg and have only one thing.

                                                To take a specific example, if the plain text representation of this email
                                                is available at localhost/2234, and I wanted to interact with the plain/text
                                                media type with that resource, I could do so by using it's identifier. I
                                                could also endup using conneg so that I could receive the text in both UTF-8
                                                and UTF-16 variations. If, on the other hand, I was maintaining a French and
                                                an English version of that message, I would find it useful to update the
                                                French version without impacting the English version. While they may carry
                                                the same meaning, the French and English versions are hardly the "same"
                                                thing, as the difference between the two languages will always trigger some
                                                slight variations in the meaning of the text.

                                                Those two language variations may well be "the response Sebastien is giving
                                                to Mike", but the two messages are two distinct texts, that are distinct
                                                things: "the French response" and "the English response". And that's why
                                                they'd have two distinct identifiers and be two distinct resources.


                                                > So it's hard, from that, to make sense of whether or not treating a
                                                > representation as a resource 'ought to be enough'. This is particularly
                                                > apparent given, as I mentioned before, the only significant benefit
                                                > from
                                                > doing this is that you get *plain text* hyperlinks to your
                                                > representations - the value of this is questionable if an identifier to
                                                > a resource is 'enough' in the first place.

                                                So you suggest that identifying a resource and dereferencing identifiers by
                                                following hyperlink controls is not enough to navigate application state?

                                                You're either proposing a new identifier that includes http control data, or
                                                you're not happy with how the web currently works. Either way, I'm not so
                                                sure what you're suggesting is actually buying, to http, to ReST, or to the
                                                web.

                                                > > The state transition is the result of dereferencing such identifier,
                                                > and is
                                                > > dependent on the state of the application. As such, it is of course
                                                > > dependent on the current state the client has, if any, and the
                                                > current state
                                                > > the server holds.
                                                > >
                                                >
                                                > If it is possible for a hyperlink to include control data, then a
                                                > hypermedia driven state transition is more than simply dereferencing an
                                                > href URI.

                                                No, hyperlink controls do not do that. Let's take an example of a well-known
                                                control. <form action="/" method="POST" enctype="multipart/form-data" />

                                                The URI in action is the identifier to the resource for which an operation
                                                will execute. Everything else is a hint to the user-agent to let it
                                                understand the representation format it can send, and the http method being
                                                expected from it.

                                                What this means is that the target resource is identified by its URI. The
                                                state transition is helped by hinting to the UA how to process the
                                                transition, aka how to build the representation that will be used in the
                                                transition.

                                                At no point is there a new identifier for (/ with POST with mediatype
                                                multipart). That would be a new identifier entirely, and one I see very
                                                little value in. At no point either is there any assertion that the target
                                                resource only support the multipart/form-data media type, or that you can
                                                only operate on it with the POST method.

                                                That's why this data is part of a hypermedia link, and why this hypermedia
                                                link contains both the identifier and the mean to interact with it.

                                                Nothing prevents me from achieving the same result by using OPTIONS to
                                                discover the methods and the media types (using the Link: header) and
                                                achieve the same state transition.

                                                That's why I said they were at different levels in the stack. Resources are
                                                things, representations are what you use to manipulate things, and
                                                hypermedia controls are the hints that help the UA discover resources and
                                                build the representations to manipulate those things.

                                                The core of your argument has been around conneg, but I think you're wanting
                                                to see more in conneg than what it was designed for, and I still do not
                                                understand why it is such an issue to identify distinct things distinctly.

                                                Maybe if you could provide some scenarios that you cannot achieve through
                                                the current understanding of what resources and representations are in the
                                                context of ReST we could have a better substrate for conversation.

                                                Seb
                                              • Mike Kelly
                                                Seb, Essentially: I don t assume just because I need to provide a hyperlink to a representation, that it must have its own URI. Maybe it is possible to have a
                                                Message 23 of 25 , Jul 27, 2009
                                                • 0 Attachment
                                                  Seb,

                                                  Essentially: I don't assume just because I need to provide a hyperlink
                                                  to a representation, that it must have its own URI. Maybe it is possible
                                                  to have a new type of hypermedia with hyperlinks capable of providing
                                                  control data to a UA - I don't see this as far different from using the
                                                  end of a URI - other than the clear benefits of keeping the distinction
                                                  between resources and representations clear.

                                                  Specific responses below:


                                                  Sebastien Lambla wrote:
                                                  >>> I'm not sure if I understand the distinction you make between
                                                  >>> application and resource state
                                                  >>>
                                                  >>> XHTML / JSON formats are an attribute of the resource representation
                                                  >>>
                                                  >> -
                                                  >>
                                                  >>> they cannot be an attribute of the application state, since from an
                                                  >>> application perspective, the user is exactly at the same place in the
                                                  >>> overall workflow irrespective of the resource representation.
                                                  >>>
                                                  >> This seems to imply tight coupling between resource and application
                                                  >> state. I can't agree that these are the same states from an application
                                                  >> perspective because they are clearly distinguished by control data in
                                                  >> the HTTP message (Accept/Content-Type in this specific case).
                                                  >>
                                                  >
                                                  > I'm going back to what I stated before. If you care about identifying
                                                  > separate things, then they should be separate things. Conneged
                                                  > representations are *not* separate things because they share the same
                                                  > identifier.
                                                  >

                                                  Again, your terminology is confusing.

                                                  Separate representations are separate 'things'.

                                                  They aren't separate resources; which is why they are treated as
                                                  representations of a single resource.. and given the same *resource*
                                                  identifier. That is all a URI is for.

                                                  > The application state is dependent on you navigating between things, not
                                                  > between representation of those things. If the representations have a
                                                  > meaningful distinction for the continuation of the state transitions, they
                                                  > should have identifiers.

                                                  Again, I'm confused by this notion of 'things'. If I substitute in
                                                  'resource' instead, the distinction that can be drawn between resource
                                                  and representation seems to become uncomfortably vague, and so you have
                                                  to question whether there is any value in the distinction at all.


                                                  > The identifiers we have are URIs to resources. If
                                                  > representations matter, then they should have their own identifiers, as such
                                                  > be promoted to resources themselves.
                                                  >

                                                  Yes - I'm still clear that representations *can* be treated as if they
                                                  were resources! :)

                                                  > Let's put it another way. If your application state depends not only on the
                                                  > existing identifier, but also in control state data, you have indeed created
                                                  > a new identifier, aka (URI+Method+Accept headers). I fail to see what this
                                                  > brings you, as opposed to simply identify representations as separate
                                                  > things?
                                                  >

                                                  Self-descriptive messages that contain no ambiguity whatsoever over what
                                                  resource was being requested and how the representation was negotiated.
                                                  What do you get other than plain text hyperlinks to representations?!

                                                  > Client-driven conneg can only work for resource representations that do not
                                                  > differ enough to be meaningful to either the UA or the application state,
                                                  > hence why there is no provision for the extra data required to identify
                                                  > those.
                                                  >

                                                  You mean like accept headers?

                                                  > You say it yourself in the next paragraph:
                                                  >

                                                  I don't if you're reading that from my perspective on what constitutes
                                                  application state (i.e. the entire message).

                                                  >
                                                  >>> If a bookmark is not a stored reference to a given application
                                                  >>> state, what is it?
                                                  >>>
                                                  >>> In this context it is a stored reference to an application state + a
                                                  >>> preferred format.
                                                  >>>
                                                  >> The array of representations for a given resource are not application
                                                  >> states in their own right?
                                                  >>
                                                  >> How would you model negotiating these formats in a state machine,
                                                  >> without treating them as separate states?
                                                  >>
                                                  >
                                                  > If they have any meaningful distinction, then you represent them as
                                                  > separately identified resources. If they do not have meaningful distinction,
                                                  > then you don't.
                                                  >

                                                  That's true *if* a state can only be defined by a URI, and not the rest
                                                  of the message.

                                                  >
                                                  >> I understand that a representation can be 'made a resource', although
                                                  >> the phrase 'treated as if it were' would be more appropriate.
                                                  >>
                                                  >
                                                  > I'm afraid we may just not be using the same terminology. I use the word
                                                  > 'identifier' with the meaning of 'identifying a resource', and 'resource' as
                                                  > 'the smallest unit i can deal with when doing state transitions in ReST'

                                                  "A resource is a conceptual mapping to a set of entities, not the entity
                                                  that corresponds to the mapping at any particular point in time."

                                                  > and
                                                  > as 'the thing / conceptual mapping / awww:resource identified by an
                                                  > identifier'. As such, I object strongly to the idea that there would be such
                                                  > a thing as 'treating a thing as a resource'. If it's important enough for me
                                                  > to interact with, and if it's identified, it's a resource.
                                                  >
                                                  >

                                                  ... :)

                                                  >> It's slightly confusing when you state that an identifier to a resource
                                                  >> is 'enough', and then immediately contradict this position by
                                                  >> entertaining 'the case that you want to identify a specific
                                                  >> representation'.
                                                  >>
                                                  >
                                                  > I apologize for introducing confusion. Let me attempt to reformulate better.
                                                  >
                                                  > If you want to interact with a thing, it has to be a resource. If you want
                                                  > to interact with two things distinctively, they are then fundamentally, by
                                                  > the ReST and HTTP requirement of resources having an identifier, two
                                                  > distinct resources. If however you interact with a single resource, that has
                                                  > multiple representations that you do not need to address specifically, then
                                                  > you may use conneg and have only one thing.
                                                  >
                                                  > To take a specific example, if the plain text representation of this email
                                                  > is available at localhost/2234, and I wanted to interact with the plain/text
                                                  > media type with that resource, I could do so by using it's identifier. I
                                                  > could also endup using conneg so that I could receive the text in both UTF-8
                                                  > and UTF-16 variations. If, on the other hand, I was maintaining a French and
                                                  > an English version of that message, I would find it useful to update the
                                                  > French version without impacting the English version. While they may carry
                                                  > the same meaning, the French and English versions are hardly the "same"
                                                  > thing, as the difference between the two languages will always trigger some
                                                  > slight variations in the meaning of the text.
                                                  >

                                                  Actually the language example is exactly the kind of situation that can
                                                  warrant the translated documents to be treated as resources, with
                                                  separate URIs.

                                                  This is because the documents are actually being treated as separate
                                                  resources in their own right - where one is updated, and the other is
                                                  non-equivalent until it is translated and updated at some other point in
                                                  time.

                                                  If that system worked in a way which tied the two together by
                                                  automatically translating an update of one to the other, then I would be
                                                  inclined to use HTTP conneg instead.

                                                  > Those two language variations may well be "the response Sebastien is giving
                                                  > to Mike", but the two messages are two distinct texts, that are distinct
                                                  > things: "the French response" and "the English response". And that's why
                                                  > they'd have two distinct identifiers and be two distinct resources.
                                                  >

                                                  Yep, no problem with that particular example - it's likely the right way
                                                  to go given the problems associated with automated translation.

                                                  >> So it's hard, from that, to make sense of whether or not treating a
                                                  >> representation as a resource 'ought to be enough'. This is particularly
                                                  >> apparent given, as I mentioned before, the only significant benefit
                                                  >> from
                                                  >> doing this is that you get *plain text* hyperlinks to your
                                                  >> representations - the value of this is questionable if an identifier to
                                                  >> a resource is 'enough' in the first place.
                                                  >>
                                                  >
                                                  > So you suggest that identifying a resource and dereferencing identifiers by
                                                  > following hyperlink controls is not enough to navigate application state?
                                                  >

                                                  Not if I want to link to specific representations of a resource, no.

                                                  > You're either proposing a new identifier that includes http control data, or
                                                  > you're not happy with how the web currently works. Either way, I'm not so
                                                  > sure what you're suggesting is actually buying, to http, to ReST, or to the
                                                  > web.
                                                  >
                                                  >

                                                  I'm actually suggesting a new form of hypermedia which provides markup
                                                  for hyperlinks that can include control data i.e.:

                                                  <a href="/resource" accept="application/pdf">link to pdf representation</a>

                                                  >>> The state transition is the result of dereferencing such identifier,
                                                  >>>
                                                  >> and is
                                                  >>
                                                  >>> dependent on the state of the application. As such, it is of course
                                                  >>> dependent on the current state the client has, if any, and the
                                                  >>>
                                                  >> current state
                                                  >>
                                                  >>> the server holds.
                                                  >>>
                                                  >>>
                                                  >> If it is possible for a hyperlink to include control data, then a
                                                  >> hypermedia driven state transition is more than simply dereferencing an
                                                  >> href URI.
                                                  >>
                                                  >
                                                  > No, hyperlink controls do not do that. Let's take an example of a well-known
                                                  > control. <form action="/" method="POST" enctype="multipart/form-data" />
                                                  >
                                                  > The URI in action is the identifier to the resource for which an operation
                                                  > will execute. Everything else is a hint to the user-agent to let it
                                                  > understand the representation format it can send, and the http method being
                                                  > expected from it.
                                                  >
                                                  > What this means is that the target resource is identified by its URI. The
                                                  > state transition is helped by hinting to the UA how to process the
                                                  > transition, aka how to build the representation that will be used in the
                                                  > transition.
                                                  >
                                                  > At no point is there a new identifier for (/ with POST with mediatype
                                                  > multipart). That would be a new identifier entirely, and one I see very
                                                  > little value in. At no point either is there any assertion that the target
                                                  > resource only support the multipart/form-data media type, or that you can
                                                  > only operate on it with the POST method.
                                                  >
                                                  > That's why this data is part of a hypermedia link, and why this hypermedia
                                                  > link contains both the identifier and the mean to interact with it.
                                                  >
                                                  > Nothing prevents me from achieving the same result by using OPTIONS to
                                                  > discover the methods and the media types (using the Link: header) and
                                                  > achieve the same state transition.
                                                  >
                                                  > That's why I said they were at different levels in the stack. Resources are
                                                  > things, representations are what you use to manipulate things, and
                                                  > hypermedia controls are the hints that help the UA discover resources and
                                                  > build the representations to manipulate those things.
                                                  >

                                                  I'm trying to establish whether or not state transitions include the
                                                  entire HTTP message, and if so - whether hypermedia controls should
                                                  provide the mechanisms to indicate control data.

                                                  I understand the practical limitations of browsers and HTML - you
                                                  haven't actually said much here about HTTP or potential hypermedia
                                                  formats/controls.

                                                  > The core of your argument has been around conneg, but I think you're wanting
                                                  > to see more in conneg than what it was designed for, and I still do not
                                                  > understand why it is such an issue to identify distinct things distinctly.
                                                  >

                                                  Identify distinct resources with resource identifiers. Negotiate
                                                  representations of resources with the appropriate conneg controls.
                                                  Create hypermedia formats which allow the server to specify a hyperlink
                                                  with specific control data required to negotiate a specific representation.

                                                  > Maybe if you could provide some scenarios that you cannot achieve through
                                                  > the current understanding of what resources and representations are in the
                                                  > context of ReST we could have a better substrate for conversation.
                                                  >

                                                  Pretend twitter doesn't use (.xml/.json/.html) URIs to separate
                                                  representations of a tweet.

                                                  How could I add links to my homepage for each of the xml, json, and html
                                                  representations?

                                                  An accept attribute in the hyperlink would work:

                                                  <a href="twitter.com/tweet/1234" accept="application/xml">xml of my
                                                  tweet</a>
                                                  <a href="twitter.com/tweet/1234" accept="application/json">json of my
                                                  tweet</a>
                                                  <a href="twitter.com/tweet/1234">Default (HTML) of my tweet</a>

                                                  If I decided I wanted to update the tweet; a PUT would automatically
                                                  invalidate the cache for all representations at the URI - and any other
                                                  intermediary could see exactly which resource the request/response
                                                  messages were about without having to assume any relationships between
                                                  any (what are supposed to be opaque) URIs.

                                                  Cheers,
                                                  Mike
                                                • Sebastien Lambla
                                                  ... That s the state of web architecture, and of ReST over http. ... URIs identify resources. If you provide a new media type that requires both URI and
                                                  Message 24 of 25 , Jul 27, 2009
                                                  • 0 Attachment
                                                    > Essentially: I don't assume just because I need to provide a hyperlink
                                                    > to a representation, that it must have its own URI.

                                                    That's the state of web architecture, and of ReST over http.

                                                    > Maybe it is
                                                    > possible
                                                    > to have a new type of hypermedia with hyperlinks capable of providing
                                                    > control data to a UA - I don't see this as far different from using the
                                                    > end of a URI - other than the clear benefits of keeping the distinction
                                                    > between resources and representations clear.

                                                    URIs identify resources. If you provide a new media type that requires both
                                                    URI and control data, you created a new identifier, one that is not a URI
                                                    only, and one that is not in use by the rest of the web architecture.

                                                    > > I'm going back to what I stated before. If you care about identifying
                                                    > > separate things, then they should be separate things. Conneged
                                                    > > representations are *not* separate things because they share the same
                                                    > > identifier.
                                                    > >
                                                    >
                                                    > Again, your terminology is confusing.

                                                    It seems to be a leitmotiv of this conversation. Let's try once more.

                                                    > Separate representations are separate 'things'.
                                                    >
                                                    > They aren't separate resources; which is why they are treated as
                                                    > representations of a single resource.

                                                    A resource is a thing, anything, that has an identifier.

                                                    A thing, anything, that doesn't have an identifier, is not a resource.

                                                    A thing, anything, that you need to identify or operate upon by applying a
                                                    state transition has to be a resource.

                                                    The identifier in ReST over http is the URI.

                                                    > > The application state is dependent on you navigating between things,
                                                    > not
                                                    > > between representation of those things. If the representations have a
                                                    > > meaningful distinction for the continuation of the state transitions,
                                                    > they
                                                    > > should have identifiers.
                                                    >
                                                    > Again, I'm confused by this notion of 'things'. If I substitute in
                                                    > 'resource' instead, the distinction that can be drawn between resource
                                                    > and representation seems to become uncomfortably vague, and so you have
                                                    > to question whether there is any value in the distinction at all.

                                                    Let's retry this again, reformulated for hopefully more clarity.

                                                    A representation of a resource is a set of bytes that "represent" a resource
                                                    and is used as the data payload when operating resources.

                                                    It happens that sometimes a resource, when dereferenced, has one
                                                    representation that is the full and entire "representation" of the resource.
                                                    In this instance, the representation may be the resource. For example,
                                                    localhost/mycv.doc is the resource "the word document that describes Seb's
                                                    professional life". There is no need of distinction between resource and
                                                    representation, as the resulting representation is the resource.

                                                    The distinction between resource and representation is as vague as the
                                                    naming function is. If you need to identify "the last customer that
                                                    registered on my site, in html", that's a resource for which only an html
                                                    representation exists. If you need to identify "The last customer that
                                                    registered on my site", that's a resource, that happens to have an html
                                                    representation.

                                                    If you navigating the application state requires you going back to the html
                                                    version, and not for example the json version, then you have two resources
                                                    with separate identifiers, as they identify a different "thing". If it
                                                    doesn't matter to anyone, then you can have conneg on one resource with one
                                                    identifier.

                                                    As for the value of distinguishing resource and representation, it has the
                                                    value of being required to ensure a late-bound system where a resource can
                                                    be identified before a representation can be produced, or even before the
                                                    resource itself exist. Without the distinction, not only do you limit the
                                                    value of identifying things to those that have a representation that can be
                                                    retrieved, you also prevent other schemes that cannot be dereferenced, such
                                                    as mailto:.

                                                    > Self-descriptive messages that contain no ambiguity whatsoever over
                                                    > what
                                                    > resource was being requested and how the representation was negotiated.
                                                    > What do you get other than plain text hyperlinks to representations?!

                                                    A bookmark is just the plain text hyperlink. A hyperlink within a media type
                                                    may have additional hints to help in dereferencing. It still doesn't impact
                                                    the "identification" as opposed to the "dereferencing".

                                                    Identifying is done independently, and at a higher level in the web stack,
                                                    than dereferencing, and as such than representation.

                                                    >
                                                    > > Client-driven conneg can only work for resource representations that
                                                    > do not
                                                    > > differ enough to be meaningful to either the UA or the application
                                                    > state,
                                                    > > hence why there is no provision for the extra data required to
                                                    > identify
                                                    > > those.
                                                    >
                                                    > You mean like accept headers?

                                                    Again, it's a matter of layering. Resources require URIs. Http require
                                                    resources. The operation of identifying a resource is not tied to http,
                                                    accept headers are metadata to help find a suitable representation when
                                                    dereferencing.

                                                    Media types are at the right level in the stack to add control data to hint
                                                    as to which representation may be retrieved, but they don't change the
                                                    semantics of resource identification.

                                                    I think your question comes down to "shouldn't they, by specializing", and
                                                    i've already made my point clear: creating a new resource when you want to
                                                    uniquely identify something is enough, requires less changes to webarch, and
                                                    is cheap.

                                                    > > You say it yourself in the next paragraph:
                                                    >
                                                    > I don't if you're reading that from my perspective on what constitutes
                                                    > application state (i.e. the entire message).

                                                    I am making the point that application state is the sum of identifications,
                                                    hypermedia controls, current state on the server and current state on the
                                                    client. If your question was, can one resume a state transition by
                                                    bookmarking the state of the current application, and be brought back to
                                                    where they were, then this would depend on the state on the client: if the
                                                    page is in cache, and the data in the form has been persisted by the browser
                                                    when bookmarking, then yes. If there is no cache, and only a URI exist, it's
                                                    up to the client to re-request state from the server to "rehydrate" itself.

                                                    The browser cache, and whatever data is saved when bookmarking, is the local
                                                    storage that is part of the general application state.

                                                    Application crash recovery in browsers is a good example of persisted
                                                    application state being resumed, so it's already there, but it encompasses
                                                    all the state that was on the client that compose part of the application
                                                    state.

                                                    Redefining the identifier mechanism to solve the false problem of conneg is
                                                    not buying you enough to be useful, when the existing mechanism can work
                                                    just as well without redefining such an essential functionality.

                                                    > That's true *if* a state can only be defined by a URI, and not the rest
                                                    > of the message.

                                                    Application State is not defined by either. It's defined by the whole of the
                                                    browser cache, local storage, content of forms, plus everything that's on
                                                    the server. If you loose the state on the client, being able to bookmark a
                                                    specific representation won't buy you any better functionality than the one
                                                    that already exist.

                                                    > > I'm afraid we may just not be using the same terminology. I use the
                                                    > word
                                                    > > 'identifier' with the meaning of 'identifying a resource', and
                                                    > 'resource' as
                                                    > > 'the smallest unit i can deal with when doing state transitions in
                                                    > ReST'
                                                    >
                                                    > "A resource is a conceptual mapping to a set of entities, not the
                                                    > entity
                                                    > that corresponds to the mapping at any particular point in time."

                                                    Then I think you'll agree with me that at no point in the ReST discertation,
                                                    or in webarch for that matter, is anyone talking about identifying and
                                                    manipulating the set of entities themselves, without the 'resource' concept.

                                                    It so happens that the resource in question may be "the customer as xml" as
                                                    opposed to "the customer".

                                                    > I'm actually suggesting a new form of hypermedia which provides markup
                                                    > for hyperlinks that can include control data i.e.:
                                                    >
                                                    > <a href="/resource" accept="application/pdf">link to pdf
                                                    > representation</a>

                                                    Adding such a hint to a specific media type is possible, and the <link> tag
                                                    already does that. But it's a hint, not part of the identification function.

                                                    If it was, you suddenly couldn't copy n paste a URL, or email it to someone
                                                    else, or link it in a wiki or an atom feed.

                                                    > Identify distinct resources with resource identifiers. Negotiate
                                                    > representations of resources with the appropriate conneg controls.
                                                    > Create hypermedia formats which allow the server to specify a hyperlink
                                                    > with specific control data required to negotiate a specific
                                                    > representation.

                                                    See above, if you "require" the control data, you redefine the
                                                    identification functionality and break the rest of the web architecture.

                                                    Not ignoring the rest of the message, but my argument will be the same.

                                                    Seb
                                                  • Mike Kelly
                                                    ... So hyperlink === URI ? i.e. link - the hyperlink is simply the value of href attribute and not the whole
                                                    Message 25 of 25 , Aug 4, 2009
                                                    • 0 Attachment
                                                      Sebastien Lambla wrote:
                                                      >> Essentially: I don't assume just because I need to provide a hyperlink
                                                      >> to a representation, that it must have its own URI.
                                                      >>
                                                      >
                                                      > That's the state of web architecture, and of ReST over http.
                                                      >

                                                      So hyperlink === URI ?

                                                      i.e. <a href="/foo/bar" accept="application/xml">link</a> - the
                                                      hyperlink is simply the value of href attribute and not the whole thing?

                                                      >
                                                      >> Maybe it is
                                                      >> possible
                                                      >> to have a new type of hypermedia with hyperlinks capable of providing
                                                      >> control data to a UA - I don't see this as far different from using the
                                                      >> end of a URI - other than the clear benefits of keeping the distinction
                                                      >> between resources and representations clear.
                                                      >>
                                                      >
                                                      > URIs identify resources. If you provide a new media type that requires both
                                                      > URI and control data, you created a new identifier, one that is not a URI
                                                      > only, and one that is not in use by the rest of the web architecture.
                                                      >
                                                      >

                                                      URI's *should* identify resources. But resources need to be identified
                                                      appropriately. If the rationale is essentially "I want to serve a client
                                                      this representation, so it needs a URI", what is the point in drawing a
                                                      distinction between resources and representations?

                                                      RPC endpoints like /app/updateSomethingSomewhere aren't resources.

                                                      Representations aren't resources. Sometimes there may be 'things' that
                                                      share a similar meaning, but have a different media type - those may
                                                      very well be separate resources and not representations at all which is
                                                      fine; give them each their own URI.

                                                      I'm concerned here with correctly identified resources that have
                                                      multiple representations.

                                                      > If it was, you suddenly couldn't copy n paste a URL, or email it to someone
                                                      > else, or link it in a wiki or an atom feed.
                                                      >


                                                      Right - so you gain plain text hyperlinks to 'representations' that
                                                      aren't actually representations at all; they're resources.

                                                      There are potential solutions to the plain text URI and conneg 'problem'
                                                      - e.g. browsers outputting an html hyperlink when copying a URI from the
                                                      location bar, or something like an 'open with' menu for hyperlinks
                                                      (powered by an OPTIONS request to the resource which lists available
                                                      content-types/languages/encodings/etc.).

                                                      Cheers,
                                                      Mike
                                                    Your message has been successfully submitted and would be delivered to recipients shortly.