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

Re: [rest-discuss] Re: The Use of Metadata in URIs: How long does a FORM assertion last?

Expand Messages
  • Roy T. Fielding
    ... I don t see why we should care. Anyone is authorized to write any software. Anyone is authorized to perform a GET on any URI. The server will respond
    Message 1 of 22 , May 1, 2008
    View Source
    • 0 Attachment
      On Apr 30, 2008, at 10:20 PM, Nick Gall wrote:
      > "Not clear what Bob's software is doing"? Do you really believe
      > that, Mark? I think it's pretty darn clear what the TAG thinks the
      > software is doing:
      >
      >
      > "Bob if he views the source of the form is assured that the
      > assigning authority issupporting an entire class of URIs of the
      > form: http://example.org/cityweather?city=CityName. ... Bob could,
      > with this assurance, write his ownsoftware to construct and use
      > such URIs to retrieve weather reports."
      >
      > The TAG is clearly not suggesting that Bob is merely authorized by
      > the FORM to write generic FORM-parsing software as you suggest. On
      > the contrary, It is clearly stating that given the specific
      > "weather URI" parameters that appear in the FORM, Bob is authorized
      > to write software that can generate "an entire class of URIs" "to
      > retrieve weather reports". In other words the software can use a
      > URI template.

      I don't see why we should care. Anyone is "authorized" to write any
      software.
      Anyone is authorized to perform a GET on any URI. The server will
      respond
      however it sees fit. The document got stuck in the weeds somewhere and
      is struggling to make sense out of nonsense.

      Don't read too much into what is obviously a poor choice of words.
      What they meant to say is that some services correspond to a range
      (template) of URIs for which guessing the potential values in that
      range is a perfectly reasonable thing to do, even if there turns
      out to be no resource for a given guess. There are no guarantees
      on the Web.

      ....Roy
    • Stefan Eissing
      The HTML form is just one way of discovering a RESTful service or, better named, a family of resources with a commen URL pattern (which hopefully is
      Message 2 of 22 , May 1, 2008
      View Source
      • 0 Attachment
        The HTML form is just one way of discovering a RESTful "service" or,
        better named, a family of resources with a commen URL pattern (which
        hopefully is expressable in URI templates). A friend sending you the
        uri template or telling you about it in suaheli are other ways to
        discover the same thing.

        If that is worth the investement to hard-code that in software is
        entirely up to you.

        //Stefan

        resources with structure
        inviting retrieval of content
        - cache control.

        Am 01.05.2008 um 07:20 schrieb Nick Gall:

        > On Thu, May 1, 2008 at 12:12 AM, Mark Baker <distobj@...> wrote:
        > > I would hope that the software Bob is writing just parses the form,
        > > and doesn't assume the URI structure will remain static for all
        > time.
        > > It's not clear what Bob's software is doing there though, so it
        > could
        > > probably use a clarification.
        >
        > "Not clear what Bob's software is doing"? Do you really believe
        > that, Mark? I think it's pretty darn clear what the TAG thinks the
        > software is doing:
        >
        >
        > "Bob if he views the source of the form is assured that the
        > assigning authority issupporting an entire class of URIs of the
        > form: http://example.org/cityweather?city=CityName. ... Bob could,
        > with this assurance, write his ownsoftware to construct and use
        > such URIs to retrieve weather reports."
        >
        > The TAG is clearly not suggesting that Bob is merely authorized by
        > the FORM to write generic FORM-parsing software as you suggest. On
        > the contrary, It is clearly stating that given the specific
        > "weather URI" parameters that appear in the FORM, Bob is authorized
        > to write software that can generate "an entire class of URIs" "to
        > retrieve weather reports". In other words the software can use a
        > URI template.
        >
        > > Why don't you bring it up with them?
        >
        > Good idea. I wanted to check with this group to see if I was just
        > confused about the finding before going to the TAG. Plus, I am
        > hoping some of them will read my post here and respond. If they
        > don't, I'll forward a part of the thread to them.
        >
        > I'll suggest that if they do intend that the mere appearance of a
        > FORM in an HTML representation assures a developer that the FORM's
        > parameters will be long lived enough to justify writing URI-
        > template-processing software based on them, then the TAG should
        > publish a "cool FORMs don't change" good practice finding to
        > clarify their intent.
        >
        > -- Nick
        >
        >

        --
        <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
        Amtsgericht Münster: HRB5782
      • Andrew S. Townley
        ... If you have a hypermedia application client/agent that interprets the resources it receives and then uses that resource as the basis for determining the
        Message 3 of 22 , May 1, 2008
        View Source
        • 0 Attachment
          On Thu, 2008-05-01 at 00:20 -0700, Roy T. Fielding wrote:
          > Don't read too much into what is obviously a poor choice of words.
          > What they meant to say is that some services correspond to a range
          > (template) of URIs for which guessing the potential values in that
          > range is a perfectly reasonable thing to do, even if there turns
          > out to be no resource for a given guess. There are no guarantees
          > on the Web.

          If you have a hypermedia application client/agent that interprets the
          resources it receives and then uses that resource as the basis for
          determining the available state transitions supported by the server, why
          would you need to bother with guessing (or relying on a URI template)
          for an automated agent?

          Maybe I'm wrong, but I see URI templates as a pragmatic shortcut so that
          agent authors don't need to bother with interpreting the hypermedia they
          receive. This makes writing agents more in line with standard modes of
          thinking about software design and implementation, e.g. to accomplish a
          task, you make calls to functions with known parameters in an order
          determined by the caller to trigger state transitions and/or receive
          some expected output.

          However, if that's the way you approach development of a hypermedia
          application where the service has the opportunity - by design - to tell
          you about the available state transitions and the location of other
          resources that it thinks are related/relevant to the current resource,
          how is your agent really part of a hypermedia application?

          As Nick pointed out, there aren't many systems out there that do this
          (interactive Web browsers being a notable exception). I think this is
          one of the drivers for the sem-web initiatives, but I also think there's
          value in trying to leverage this approach today to build more robust
          software systems that can gracefully handle changes in the service
          implementation.

          ast
          --
          Andrew S. Townley <ast@...>
          http://atownley.org
        • Peter Williams
          ... Well, it may be that many people use URI templates as a shortcut for using hypermedia but there *are* valid uses of URI templates that do not entail
          Message 4 of 22 , May 1, 2008
          View Source
          • 0 Attachment
            Andrew S. Townley wrote:
            >
            > Maybe I'm wrong, but I see URI templates as a pragmatic shortcut so that
            > agent authors don't need to bother with interpreting the hypermedia they
            > receive. This makes writing agents more in line with standard modes of
            > thinking about software design and implementation, e.g. to accomplish a
            > task, you make calls to functions with known parameters in an order
            > determined by the caller to trigger state transitions and/or receive
            > some expected output.

            Well, it may be that many people use URI templates as a shortcut for
            using hypermedia but there *are* valid uses of URI templates that do
            not entail cheating.

            For example, in the application on which I work tracks time series
            data for a large number of metrics. Each metric is a resource, as is
            the observations for those metrics. Many (non-browser) agents need all
            the observations from specific time frames to perform their work. To
            facilitate this we have provided a "link" in the metric
            representations to any time based subset of the observations for that
            metric using a template. For example,

            http://foo.example/metrics/232/observations?start={start_time}&end={end_time}

            This works quite well for us, and I cannot think of any other approach
            that would be as efficient and simple. It is worth noting that we do
            not guarantee that URL will exist in the future. Rather, we guarantee
            that there will be a URL template in the metric representations that
            you can substitute `start_time` and `end_time` into and use get the
            set of observation in that time frame.

            Peter Williams
            http://pezra.barelyenough.org
          • Andrew S. Townley
            ... Hi Peter, So, are you saying that you embed the template in the representation for http://foo.example/metrics/232? If so, why wouldn t you just put a 2
            Message 5 of 22 , May 1, 2008
            View Source
            • 0 Attachment
              On Thu, 2008-05-01 at 08:51 -0600, Peter Williams wrote:
              > Andrew S. Townley wrote:
              > >
              > > Maybe I'm wrong, but I see URI templates as a pragmatic shortcut so that
              > > agent authors don't need to bother with interpreting the hypermedia they
              > > receive. This makes writing agents more in line with standard modes of
              > > thinking about software design and implementation, e.g. to accomplish a
              > > task, you make calls to functions with known parameters in an order
              > > determined by the caller to trigger state transitions and/or receive
              > > some expected output.
              >
              > Well, it may be that many people use URI templates as a shortcut for
              > using hypermedia but there *are* valid uses of URI templates that do
              > not entail cheating.
              >
              > For example, in the application on which I work tracks time series
              > data for a large number of metrics. Each metric is a resource, as is
              > the observations for those metrics. Many (non-browser) agents need all
              > the observations from specific time frames to perform their work. To
              > facilitate this we have provided a "link" in the metric
              > representations to any time based subset of the observations for that
              > metric using a template. For example,
              >
              > http://foo.example/metrics/232/observations?start={start_time}&end={end_time}
              >
              > This works quite well for us, and I cannot think of any other approach
              > that would be as efficient and simple. It is worth noting that we do
              > not guarantee that URL will exist in the future. Rather, we guarantee
              > that there will be a URL template in the metric representations that
              > you can substitute `start_time` and `end_time` into and use get the
              > set of observation in that time frame.

              Hi Peter,

              So, are you saying that you embed the template in the representation
              for
              http://foo.example/metrics/232? If so, why wouldn't you just put a 2
              field form there instead? I agree that it means you don't have the
              ability to just make one request. If the template's in the resource
              anyway, I would see the form as being less work to ensure you were
              constructing the correct URIs because the representation+form would do
              it for you automatically.

              Cheers,

              ast
              --
              Andrew S. Townley <ast@...>
              http://atownley.org
            • Peter Williams
              ... The main reason is that the representations I am thinking of are JSON documents that look a bit like this: { _type : Metric ,
              Message 6 of 22 , May 1, 2008
              View Source
              • 0 Attachment
                Andrew S. Townley wrote:
                >> For example, in the application on which I work tracks time series
                >> data for a large number of metrics. Each metric is a resource, as is
                >> the observations for those metrics. Many (non-browser) agents need all
                >> the observations from specific time frames to perform their work. To
                >> facilitate this we have provided a "link" in the metric
                >> representations to any time based subset of the observations for that
                >> metric using a template. For example,
                >>
                >> http://foo.example/metrics/232/observations?start={start_time}&end={end_time}
                >
                > So, are you saying that you embed the template in the representation
                > for
                > http://foo.example/metrics/232? If so, why wouldn't you just put a 2
                > field form there instead? I agree that it means you don't have the
                > ability to just make one request. If the template's in the resource
                > anyway, I would see the form as being less work to ensure you were
                > constructing the correct URIs because the representation+form would do
                > it for you automatically.


                The main reason is that the representations I am thinking of are JSON
                documents that look a bit like this:

                {
                "_type": "Metric",
                "observations_in_interval_href":
                "http://foo.example/metrics/232/observations?start={start_time}&end={end_time}",
                }

                (There are lots of other attributes of course.) So using a form is not
                really a very appealing option. However, we do implement this as a two
                field form in the HTML representations.

                Hope that clears up the confusion.

                --
                Peter Williams
                http://pezra.barelyenough.org
              • Nick Gall
                On Thu, May 1, 2008 at 10:51 AM, Peter Williams ... http://foo.example/metrics/232/observations?start={start_time}&end={end_time} ...
                Message 7 of 22 , May 1, 2008
                View Source
                • 0 Attachment
                  On Thu, May 1, 2008 at 10:51 AM, Peter Williams <pezra@...> wrote:
                  > For example, in the application on which I work tracks time series
                  > data for a large number of metrics. Each metric is a resource, as is
                  > the observations for those metrics. Many (non-browser) agents need all
                  > the observations from specific time frames to perform their work. To
                  > facilitate this we have provided a "link" in the metric
                  > representations to any time based subset of the observations for that
                  > metric using a template. For example,
                  >
                  > http://foo.example/metrics/232/observations?start={start_time}&end={end_time}
                  >
                  > This works quite well for us, and I cannot think of any other approach
                  > that would be as efficient and simple. It is worth noting that we do
                  > not guarantee that URL will exist in the future. Rather, we guarantee
                  > that there will be a URL template in the metric representations that
                  > you can substitute `start_time` and `end_time` into and use get the
                  > set of observation in that time frame.

                  An elegant approach. A couple of observations/questions:
                  1. I infer from "we do not guarantee that [any observation interval] URL will exist in the future" that you've decided that such URLs should be considered ephemeral, ie not "cool URLs". Since cool URLs are good practice according to the AWWWv1 and TBL, can you share the thinking behind not following good practice? Would users never want to bookmark such observation intervals?
                  2. I assume that the URLs to the metrics are cool, eg http://foo.example/metrics/232/ . If not, what is the cool URL that bootstraps me into the system and how do I navigate to metric URLs like this one? And again, why was the decision made to not follow good practice by making metric URL ephemeral.
                  3. I am trying to measure the coupling of your approach in terms of fixed points: dependencies that must be established "out of band" before the client and server can share information. In other words, these are long-lived, static dependencies that are NOT dynamically and ephemerally established in the course of a sequence of request/replies between the client and server. I count five fixed points required to access an observation interval using the indirect method you describe:
                    1. the metric authority:http://foo.example/
                    2. the metric relative URL: metrics/232/
                    3. the JSON name/value pair for the URL template: observations_in_interval_href: <template>
                    4. the template variable name: start_time
                    5. the template variable name: stop_time
                  4. Direct use of an observation interval template alone has only four fixed points:
                    1. the observation authority: http://foo.example/
                    2. the observations relative URL: /metrics/232/observations?
                    3. the URL argument name: start
                    4. The URL argument name: end
                  5. Given that your approach has more fixed point dependencies than a simple direct use of a URL, can you explain what dependencies you were trying to eliminate and why? For example, is observations_in_interval_href less likely to change than /metrics/232/observations? Is start_time less likely to change than start?
                  As I wrote this up, it dawned on me that establishing the use of server-generated ephemeral URLs in returned representations as a good practice is effectively contradicting the cool URL good practice. The former seeks to minimize the number of cool (long lived) URLs and the latter practice seeks to maximize them. Put another way, proponents of server-generated ephemeral URLs appear to believe that long-lived URLs are not cool because they create long-lived dependencies.

                  So which is the better design -- a hypermedia application rich in long lived URLs or a hypermedia application poor in long lived URLs, just a few "bootstrap" URLs? Up til now I always assumed the former, but now I'm not so sure. Again this reminds me a bit of the deep-linking debate, eg a building with many doors vs a building with few doors.

                  -- Nick
                • Andrew S. Townley
                  ... That reminds me, I meant to get back to your earlier question to me about deep linking. In the approach I was talking about, deep linking isn t an issue,
                  Message 8 of 22 , May 1, 2008
                  View Source
                  • 0 Attachment
                    On Thu, 2008-05-01 at 16:01 -0400, Nick Gall wrote:

                    > As I wrote this up, it dawned on me that establishing the use of
                    > server-generated ephemeral URLs in returned representations as a good
                    > practice is effectively contradicting the cool URL good practice. The
                    > former seeks to minimize the number of cool (long lived) URLs and the
                    > latter practice seeks to maximize them. Put another way, proponents of
                    > server-generated ephemeral URLs appear to believe that long-lived URLs
                    > are not cool because they create long-lived dependencies.
                    >
                    > So which is the better design -- a hypermedia application rich in long
                    > lived URLs or a hypermedia application poor in long lived URLs, just a
                    > few "bootstrap" URLs? Up til now I always assumed the former, but now
                    > I'm not so sure. Again this reminds me a bit of the deep-linking
                    > debate, eg a building with many doors vs a building with few doors.

                    That reminds me, I meant to get back to your earlier question to me
                    about deep linking. In the approach I was talking about, deep linking
                    isn't an issue, because either way, the service should give you an
                    "out", i.e. a navigable state transition URI regardless of whether it
                    gives you the page you expected or not. As long as you "bookmarked" or
                    otherwise saved a URI that was given to you from the service, it follows
                    what I was trying to specify via my definition of hypermedia.

                    I hadn't thought about the cache header point that Mark made earlier,
                    but I like the idea of using it as a hint. Even if you tried to
                    dereference it after it expires, the service will hopefully give you a
                    navigable resource instead--even if it's an error page with a pointer to
                    the "front door".

                    Personally, I think that if you're only using the URIs presented to you
                    from the server (or the 'friendly' ones printed on the side of a bus
                    which are bound to be *a* 'front door' if not *the* 'front door'), then
                    you can bookmark any URI you like. My issue is with URI generation or
                    "guessing" in the case of automated agents; it's less about the TTL of
                    the particular URI. However, the TTL is more relevant if you're going
                    to use template-based approaches and you don't want your system to break
                    in the face of changes in the service.

                    ast
                    --
                    Andrew S. Townley <ast@...>
                    http://atownley.org
                  • Mark Baker
                    ... Those URLs might very well be cool, but there s just no way to communicate that (IIRC HTTP has a 1 year age limit - a good thing). But declaring a space of
                    Message 9 of 22 , May 1, 2008
                    View Source
                    • 0 Attachment
                      On Thu, May 1, 2008 at 4:01 PM, Nick Gall <nick.gall@...> wrote:
                      > I infer from "we do not guarantee that [any observation interval] URL will
                      > exist in the future" that you've decided that such URLs should be considered
                      > ephemeral, ie not "cool URLs".

                      Those URLs might very well be cool, but there's just no way to
                      communicate that (IIRC HTTP has a 1 year age limit - a good thing).
                      But declaring a space of them in an HTML form that expires in a week
                      doesn't mean they're *not* cool.

                      Mark.
                      --
                      Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
                      Coactus; Web-inspired integration strategies http://www.coactus.com
                    • Nick Gall
                      ... will ... considered ... Agreed. But what if the metrics provider explictly documented in its API documentation that we do not guarantee that [any
                      Message 10 of 22 , May 1, 2008
                      View Source
                      • 0 Attachment
                        On Thu, May 1, 2008 at 4:38 PM, Mark Baker <distobj@...> wrote:
                        > On Thu, May 1, 2008 at 4:01 PM, Nick Gall <nick.gall@...> wrote:
                        > > I infer from "we do not guarantee that [any observation interval] URL will
                        > > exist in the future" that you've decided that such URLs should be considered
                        > > ephemeral, ie not "cool URLs".
                        >
                        > Those URLs might very well be cool, but there's just no way to
                        > communicate that (IIRC HTTP has a 1 year age limit - a good thing).
                        > But declaring a space of them in an HTML form that expires in a week
                        > doesn't mean they're *not* cool.

                        Agreed. But what if the metrics provider explictly documented in its API documentation that "we do not guarantee that [any observation interval] URL will exist" beyond the client's session. I assume that such documentation would mean that the observation interval URLs were NOT cool.

                        -- Nick
                      • Roy T. Fielding
                        ... For the same reason that you would bother using Google search. Look in the HTTP spec for the phrase all modern information systems ... . ... That s one
                        Message 11 of 22 , May 1, 2008
                        View Source
                        • 0 Attachment
                          On May 1, 2008, at 2:03 AM, Andrew S. Townley wrote:
                          > On Thu, 2008-05-01 at 00:20 -0700, Roy T. Fielding wrote:
                          > > Don't read too much into what is obviously a poor choice of words.
                          > > What they meant to say is that some services correspond to a range
                          > > (template) of URIs for which guessing the potential values in that
                          > > range is a perfectly reasonable thing to do, even if there turns
                          > > out to be no resource for a given guess. There are no guarantees
                          > > on the Web.
                          >
                          > If you have a hypermedia application client/agent that interprets the
                          > resources it receives and then uses that resource as the basis for
                          > determining the available state transitions supported by the
                          > server, why
                          > would you need to bother with guessing (or relying on a URI template)
                          > for an automated agent?
                          >

                          For the same reason that you would bother using Google search.
                          Look in the HTTP spec for the phrase "all modern information
                          systems ...".

                          > Maybe I'm wrong, but I see URI templates as a pragmatic shortcut so
                          > that
                          > agent authors don't need to bother with interpreting the hypermedia
                          > they
                          > receive. This makes writing agents more in line with standard modes of
                          > thinking about software design and implementation, e.g. to
                          > accomplish a
                          > task, you make calls to functions with known parameters in an order
                          > determined by the caller to trigger state transitions and/or receive
                          > some expected output.
                          >

                          That's one way to use them, yes. The other way is computed links.

                          > However, if that's the way you approach development of a hypermedia
                          > application where the service has the opportunity - by design - to
                          > tell
                          > you about the available state transitions and the location of other
                          > resources that it thinks are related/relevant to the current resource,
                          > how is your agent really part of a hypermedia application?
                          >

                          Again, the other way is computed links (see hypertext research).

                          > As Nick pointed out, there aren't many systems out there that do this
                          > (interactive Web browsers being a notable exception). I think this is
                          > one of the drivers for the sem-web initiatives, but I also think
                          > there's
                          > value in trying to leverage this approach today to build more robust
                          > software systems that can gracefully handle changes in the service
                          > implementation.
                          >

                          There are many systems that use computed links. Almost all of the
                          closed-world hypertext systems had automated dictionary lookup
                          (click on any non-linked word and it retrieves the dictionary
                          entry for that word). Programming IDEs do much the same. A template
                          is just a way for a server to tell a client that there is a range
                          of resources available -- just like server-side image maps, HTML
                          forms, and (in less visible ways) javascript. As long as the template
                          is defined by the server, they are still links. As long as the template
                          is defined by the server in a recent representation, it is RESTful.

                          ....Roy
                        • Andrew S. Townley
                          ... Sorry for being thick, but I m not quite sure the point you re trying to make here. The closest I could find was in 1.1 Purpose: Practical information
                          Message 12 of 22 , May 1, 2008
                          View Source
                          • 0 Attachment
                            On Thu, 2008-05-01 at 14:03 -0700, Roy T. Fielding wrote:
                            > On May 1, 2008, at 2:03 AM, Andrew S. Townley wrote:
                            > > On Thu, 2008-05-01 at 00:20 -0700, Roy T. Fielding wrote:
                            > >
                            > > If you have a hypermedia application client/agent that interprets
                            > the
                            > > resources it receives and then uses that resource as the basis for
                            > > determining the available state transitions supported by the
                            > > server, why
                            > > would you need to bother with guessing (or relying on a URI
                            > template)
                            > > for an automated agent?
                            > >
                            >
                            > For the same reason that you would bother using Google search.
                            > Look in the HTTP spec for the phrase "all modern information
                            > systems ...".

                            Sorry for being thick, but I'm not quite sure the point you're trying to
                            make here. The closest I could find was in 1.1 Purpose:

                            "Practical information systems require more functionality than
                            simple retrieval, including search, front-end update, and
                            annotation."

                            Is that what you meant? If so, I understand that and agree, but I still
                            don't get your point, sorry...

                            > > As Nick pointed out, there aren't many systems out there that do
                            > this
                            > > (interactive Web browsers being a notable exception). I think this
                            > is
                            > > one of the drivers for the sem-web initiatives, but I also think
                            > > there's
                            > > value in trying to leverage this approach today to build more robust
                            > > software systems that can gracefully handle changes in the service
                            > > implementation.
                            > >
                            >
                            > There are many systems that use computed links. Almost all of the
                            > closed-world hypertext systems had automated dictionary lookup
                            > (click on any non-linked word and it retrieves the dictionary
                            > entry for that word). Programming IDEs do much the same. A template
                            > is just a way for a server to tell a client that there is a range
                            > of resources available -- just like server-side image maps, HTML
                            > forms, and (in less visible ways) javascript. As long as the template
                            > is defined by the server, they are still links. As long as the
                            > template
                            > is defined by the server in a recent representation, it is RESTful.

                            Thanks for the pointer to the computed links concept. It's been a
                            couple years since I read much of the hypertext research, and I didn't
                            remember this. With a quick google, I found this paper that looked
                            pretty relevant: "Hand-made and Computed Links, Precomputed and Dynamic
                            Links (1997)" (http://citeseer.ist.psu.edu/161116.html). From the
                            introduction:

                            "This paper surveys the use of hand-made and computed links in hypermedia systems and
                            contrasts precomputation and dynamic computation of those links which are computed.
                            This paper seeks to raise all the issues in one place, so that designers of hypermedia
                            systems can consider the issues together, whether they can afford to ignore some forms of
                            link, which forms are the most suitable to their working environment, and so on."

                            Based on a quick skim of the paper, I guess I should qualify my
                            uneasiness about URI templates. I can see how the server could specify
                            a URI template in the resource it sends to allow computed links (for
                            dictionary, glossary or other types of lookup) using JavaScript or
                            something like XForms and an agreement about what the form did as part
                            of the specification of the content model. In effect, as you say, it's
                            functionally equivalent to an HTML form, because the form effectively
                            defines the template as stated by the recommendation Nick referenced.

                            This use of template URIs still wouldn't bother me because they would be
                            defined (potentially) dynamically by the server and be a part of the
                            representation used by the client. Since they're part of the hypermedia
                            that must be processed by the client to accomplish any state transition,
                            I 100% agree that they would, in fact, be RESTful.

                            However, I see URI templates defined in a different resource -
                            especially out-of-band API documentation - as a totally different beast.
                            Admittedly, I only did a quick skim of the paper and a couple of other
                            sources, but I would find it a bit of a stretch to say that these could
                            be considered computed links of the same kind. By their very nature,
                            aren't they documented so that they can become part of the client's
                            implementation rather than having it use the information in the resource
                            from the service? The template isn't defined by the server at all in
                            this case, right, so how can this use of template URIs be RESTful?

                            Thanks again for the reference.

                            ast
                            --
                            Andrew S. Townley <ast@...>
                            http://atownley.org
                          • Peter Williams
                            ... In practice these URLs are cool , I suppose. When we change the shapes of URLs we always implement redirections from the old to the new shapes. My
                            Message 13 of 22 , May 2, 2008
                            View Source
                            • 0 Attachment
                              Nick Gall wrote:
                              > 1. I infer from "we do not guarantee that [any observation interval]
                              > URL will exist in the future" that you've decided that such URLs
                              > should be considered ephemeral, ie not "cool URLs". Since cool
                              > URLs are good practice according to the AWWWv1 and TBL, can you
                              > share the thinking behind not following good practice? Would users
                              > never want to bookmark such observation intervals?

                              In practice these URLs are "cool", I suppose. When we change the shapes
                              of URLs we always implement redirections from the old to the new shapes.

                              My statement about them not being guaranteed arose from the fact that we
                              encourage automated agents not store URLs unless it is absolutely
                              necessary. That policy is mostly about avoiding having many URLs in the
                              wild that are obsolescent and taking the multi request overhead of
                              redirection.

                              > 2. I assume that the URLs to the metrics are cool, eg
                              > http://foo.example/ metrics/232/ <http://foo.example/metrics/232/>
                              > . If not, what is the cool URL that bootstraps me into the system
                              > and how do I navigate to metric URLs like this one? And again, why
                              > was the decision made to not follow good practice by making metric
                              > URL ephemeral.

                              As with observations, any particular metric URL will be supported for a
                              long time. However that longevity may be achieved by the use of
                              redirection should we need to change the disposition of the resource.

                              As for how to navigate to the metric, we have implemented a resource
                              discovery mechanism which we generally use as the main entry point. I
                              have describing it at
                              http://pezra.barelyenough.org/blog/2008/01/restful-service-discovery-and-description/
                              if you are interested.

                              > 3. I am trying to measure the coupling of your approach in terms of
                              > fixed points: dependencies that must be established "out of band"
                              > before the client and server can share information. In other
                              > words, these are long-lived, static dependencies that are NOT
                              > dynamically and ephemerally established in the course of a
                              > sequence of request/replies between the client and server. I count
                              > five fixed points required to access an observation interval using
                              > the indirect method you describe:
                              > 1. the metric authority:http://foo.example/
                              > 2. the metric relative URL: metrics/232/
                              > 3. the JSON name/value pair for the URL template: observations_
                              > in_interval_ href: <template>
                              > 4. the template variable name: start_time
                              > 5. the template variable name: stop_time

                              I am not sure I would count 1 and 2 as separate. I generally conceive
                              of URLs as atomic entities. Other than that it looks about right.


                              > 4. Direct use of an observation interval template alone has only four
                              > fixed points:
                              > 1. the observation authority: http://foo.example/
                              > 2. the observations relative URL: /metrics/232/ observations?
                              > 3. the URL argument name: start
                              > 4. The URL argument name: end
                              > 5. Given that your approach has more fixed point dependencies than a
                              > simple direct use of a URL, can you explain what dependencies you
                              > were trying to eliminate and why? For example, is observations_
                              > in_interval_ href less likely to change than /metrics/232/
                              > observations? Is start_time less likely to change than start?

                              The main thing we were trying to achieve is to allow the server a great
                              deal of freedom in the disposition of resources. For example, if a
                              server becomes overloaded we need the freedom to relocate the
                              observations for any metrics we choose. While we can, and do, continue
                              to support obsolesce URLs via redirection, having the original location
                              of the resource forced to handle the initial requests and redirection is
                              less optimal than just having agents go to the right place in the first
                              place.

                              >
                              > As I wrote this up, it dawned on me that establishing the use of
                              > server-generated ephemeral URLs in returned representations as a good
                              > practice is effectively contradicting the cool URL good practice. The
                              > former seeks to minimize the number of cool (long lived) URLs and the
                              > latter practice seeks to maximize them. Put another way, proponents of
                              > server-generated ephemeral URLs appear to believe that long-lived URLs
                              > are not cool because they create long-lived dependencies.
                              >
                              > So which is the better design -- a hypermedia application rich in long
                              > lived URLs or a hypermedia application poor in long lived URLs, just a
                              > few "bootstrap" URLs? Up til now I always assumed the former, but now
                              > I'm not so sure. Again this reminds me a bit of the deep-linking debate,
                              > eg a building with many doors vs a building with few doors.

                              I tend to prefer having as few long lived URLs as possible. Each long
                              lived URL represents an additional maintenance burden for the system
                              over time. In my experience, however, it turns out that most URLs in a
                              system do need to be long lived. It is probably easier and safer to
                              just assume that all the URLs in a system will have to be supported for
                              a very long time.

                              --
                              Peter Williams
                              http://pezra.barelyenough.org
                            • dev
                              ... long lived URLs or a hypermedia application poor in long lived URLs, just a few bootstrap URLs? Hypermedia as the engine of application state!
                              Message 14 of 22 , May 3, 2008
                              View Source
                              • 0 Attachment
                                >So which is the better design -- a hypermedia application rich in
                                long lived URLs or a >hypermedia application poor in long lived URLs,
                                just a few "bootstrap" URLs?

                                Hypermedia as the engine of application state!
                                Hypermedia as the engine of application state!
                                HATEOAS induces loose coupling in your network application. This
                                causes interesting stuff in your application like anarchic scalability
                                etc. etc. (see Roy's Thesis). Thus you want to use HATEOAS, as much as
                                you can. You WANT to try and use the links / hrefs as much as
                                possible. Its just nice software engineering to decouple your client
                                and servers from each other.

                                "When we think about WS-* style services, there's little notion of
                                graphs of information resources. One exchanges documents with
                                embedded, "managed" data identifiers, like primary keys. The client
                                has to maintain the context of what the identifier signifies and know
                                the provider's assumptions in how, when, and where the identifier
                                should be accessed. All of these assumptions are tacit, and hence,
                                tightly coupled."[1]

                                Cool URIs are a nice etiquette . But do NOT put this above your basic
                                requirement viz. building an application that will scale to the web
                                and be able to live on the web (for which it will need various
                                interesting properties .. again see the REST-bible :)

                                The whole thrust of the "cool uris don't change" note , was that it is
                                frustrating for humans to see a dangling or broken link. But this
                                won't be the case if you are building a bot / your own application
                                that traverses your network based application.

                                While I have concentrated on Scalability till now , you know that on
                                the net it is ANARCHIC scalability. There are NO guarentees and it is
                                wrong of you to assume any (even if some "best practices" document
                                tells you to).

                                [1] http://www.stucharlton.com/blog/archives/000141.html

                                Regards
                                Devdatta

                                On 02/05/2008, Nick Gall <nick.gall@...> wrote:
                                >
                                >
                                >
                                >
                                >
                                >
                                > On Thu, May 1, 2008 at 10:51 AM, Peter Williams <pezra@...> wrote:
                                > > For example, in the application on which I work tracks time series
                                > > data for a large number of metrics. Each metric is a resource, as is
                                > > the observations for those metrics. Many (non-browser) agents need all
                                > > the observations from specific time frames to perform their work. To
                                > > facilitate this we have provided a "link" in the metric
                                > > representations to any time based subset of the observations for that
                                > > metric using a template. For example,
                                > >
                                > > http://foo.example/metrics/232/observations?start={start_time}&end={end_time}
                                > >
                                > > This works quite well for us, and I cannot think of any other approach
                                > > that would be as efficient and simple. It is worth noting that we do
                                > > not guarantee that URL will exist in the future. Rather, we guarantee
                                > > that there will be a URL template in the metric representations that
                                > > you can substitute `start_time` and `end_time` into and use get the
                                > > set of observation in that time frame.
                                >
                                > An elegant approach. A couple of observations/questions:
                                >
                                >
                                > I infer from "we do not guarantee that [any observation interval] URL will exist in the future" that you've decided that such URLs should be considered ephemeral, ie not "cool URLs". Since cool URLs are good practice according to the AWWWv1 and TBL, can you share the thinking behind not following good practice? Would users never want to bookmark such observation intervals?
                                > I assume that the URLs to the metrics are cool, eg http://foo.example/metrics/232/ . If not, what is the cool URL that bootstraps me into the system and how do I navigate to metric URLs like this one? And again, why was the decision made to not follow good practice by making metric URL ephemeral.
                                > I am trying to measure the coupling of your approach in terms of fixed points: dependencies that must be established "out of band" before the client and server can share information. In other words, these are long-lived, static dependencies that are NOT dynamically and ephemerally established in the course of a sequence of request/replies between the client and server. I count five fixed points required to access an observation interval using the indirect method you describe:
                                >
                                >
                                > the metric authority:http://foo.example/
                                > the metric relative URL: metrics/232/
                                > the JSON name/value pair for the URL template: observations_in_interval_href: <template>
                                >
                                > the template variable name: start_time
                                > the template variable name: stop_time
                                > Direct use of an observation interval template alone has only four fixed points:
                                >
                                > the observation authority: http://foo.example/
                                > the observations relative URL: /metrics/232/observations?
                                > the URL argument name: start
                                > The URL argument name: end
                                > Given that your approach has more fixed point dependencies than a simple direct use of a URL, can you explain what dependencies you were trying to eliminate and why? For example, is observations_in_interval_href less likely to change than /metrics/232/observations? Is start_time less likely to change than start? As I wrote this up, it dawned on me that establishing the use of server-generated ephemeral URLs in returned representations as a good practice is effectively contradicting the cool URL good practice. The former seeks to minimize the number of cool (long lived) URLs and the latter practice seeks to maximize them. Put another way, proponents of server-generated ephemeral URLs appear to believe that long-lived URLs are not cool because they create long-lived dependencies.
                                >
                                > So which is the better design -- a hypermedia application rich in long lived URLs or a hypermedia application poor in long lived URLs, just a few "bootstrap" URLs? Up til now I always assumed the former, but now I'm not so sure. Again this reminds me a bit of the deep-linking debate, eg a building with many doors vs a building with few doors.
                                >
                                > -- Nick
                                >
                                >
                                >
                              • Steve Loughran
                                ... . ... There s nothing wrong with disagreeing with the W3C TAG. I have a difference of opinion on testing for example (me: any standard without tests
                                Message 15 of 22 , May 7, 2008
                                View Source
                                • 0 Attachment
                                  On Thu, May 1, 2008 at 6:20 AM, Nick Gall <nick.gall@...> wrote:
                                  >
                                  > On Thu, May 1, 2008 at 12:12 AM, Mark Baker <distobj@...> wrote:
                                  .
                                  >
                                  >
                                  > > Why don't you bring it up with them?
                                  >
                                  > Good idea. I wanted to check with this group to see if I was just confused
                                  > about the finding before going to the TAG. Plus, I am hoping some of them
                                  > will read my post here and respond. If they don't, I'll forward a part of
                                  > the thread to them.

                                  There's nothing wrong with disagreeing with the W3C TAG. I have a
                                  difference of opinion on testing for example (me: any standard without
                                  tests doesn't exist), but the TAG happily waved through WS-Addressing
                                  without a single test case. I normally give my local representative a
                                  hard time about such things, when I get to corner him at the coffee
                                  machine. Speaking of which, the next TAG meeting will actually be on
                                  our site, 19-21 may. Is there anyone else I need to get hold of and
                                  raise any pressing matters?

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