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

RE: [rest-discuss] Re: MindTouch Dream

Expand Messages
  • Mike Schinkel
    ... Thanks. Reading those specs correctly is so tricky... ... That s what I was enivisoning since they are so closely related. ... I m curious; could
    Message 1 of 19 , Jan 2, 2007
    • 0 Attachment
      Benjamin Carlyle wrote:
      > "@" is legal in most parts of a uri, since it is part of the
      > pchar set.

      Thanks. Reading those specs correctly is so tricky...

      > Perhaps a cut-down
      > form of the blueprint would be more appropriate than one that
      > exposes internal classes and the like.

      That's what I was enivisoning since they are so closely related.

      > On the whole the framework doesn't look particularly RESTful
      > or non-RESTful. It would be up to a particular blueprint and
      > implementation to conform or not conform to REST principles.
      > If it is designed for interaction with HTTP and allows
      > appropriate access to HTTP headers I don't see any obvious
      > problems on the surface.

      I'm curious; could RESTfulness be more strongly enforced by the framework?

      --
      -Mike Schinkel
      http://www.mikeschinkel.com/blogs/
      http://www.welldesignedurls.org/
    • Roy T. Fielding
      ... A URI generator should percent-encode reserved characters when they are not being used as delimiters, so that other layers that do use them as delimiters
      Message 2 of 19 , Jan 2, 2007
      • 0 Attachment
        On Jan 2, 2007, at 3:57 AM, Mike Schinkel wrote:
        > Steve G. Bjorg wrote:
        > > Mike Schinkel wrote:
        > > > > Ah yes, the ugly '@' prefix. It's to avoid naming clashes
        > between
        > > > > built-in and custom URIs.
        > > >
        > > > I definitely wouldn't use something that requires encoding.
        > >
        > > It doesn't. According to [1] (section 3.3), the '@' character is
        > > legal in the URI path and does not require escaping.
        > > [1] http://www.ietf.org/rfc/rfc2396.txt
        >
        > I didn't check rfc 2396, but rfc 3986 obsoletes it. Reading from
        > "Reserved
        > Characters" section[1] it appears that you should percent encode
        > the '@'
        > character, but I could be misreading. Can anyone on the list with more
        > experience tell me if I'm interpreting it incorrectly, and if so why?

        A URI generator should percent-encode reserved characters when they
        are not being used as delimiters, so that other layers that do use
        them as delimiters can treat them specially without misinterpreting
        normal data (e.g., a name that just happens to start with @ would
        be encoded, whereas the delimiter used by Dream would not).

        In other words, Dream is using a reserved character correctly.
        Whether or not @ is the best choice for that reserved character
        is a long story and probably depends on what URIs are allowed
        (some use @ in the path for other things) and whether or not it
        interfaces with XPath processing (which uses @ for attribute names).

        ....Roy
      • Mike Schinkel
        ... Interesting. Hmmm. I m going to have to mull on that one a bit. Is it a being used as a delimiter because it denotes a special class of URLs? That would
        Message 3 of 19 , Jan 2, 2007
        • 0 Attachment
          Roy T. Fielding wrote:
          > > Steve G. Bjorg wrote:
          > > > Mike Schinkel wrote:
          > > > > > Ah yes, the ugly '@' prefix. It's to avoid naming clashes
          > > between
          > > > > > built-in and custom URIs.
          > > > >
          > > > > I definitely wouldn't use something that requires encoding.
          > > >
          > > > It doesn't. According to [1] (section 3.3), the '@' character is
          > > > legal in the URI path and does not require escaping.
          > > > [1] http://www.ietf.org/rfc/rfc2396.txt
          > >
          > > I didn't check rfc 2396, but rfc 3986 obsoletes it. Reading from
          > > "Reserved Characters" section[1] it appears that you should percent
          > > encode the '@'
          > > character, but I could be misreading. Can anyone on the
          > list with more
          > > experience tell me if I'm interpreting it incorrectly, and
          > if so why?
          >
          > A URI generator should percent-encode reserved characters
          > when they are not being used as delimiters, so that other
          > layers that do use them as delimiters can treat them
          > specially without misinterpreting normal data (e.g., a name
          > that just happens to start with @ would be encoded, whereas
          > the delimiter used by Dream would not).
          >
          > In other words, Dream is using a reserved character correctly.
          > Whether or not @ is the best choice for that reserved
          > character is a long story and probably depends on what URIs
          > are allowed (some use @ in the path for other things) and
          > whether or not it interfaces with XPath processing (which
          > uses @ for attribute names).

          Interesting. Hmmm. I'm going to have to mull on that one a bit. Is it a
          being used as a delimiter because it denotes a special class of URLs? That
          would not have occurred to me. I keep learning something new on this list
          everyday...

          Thanks.

          --
          -Mike Schinkel
          http://www.mikeschinkel.com/blogs/
          http://www.welldesignedurls.org/
        • Steve Bjorg
          ... You re absolutely right: a service can provide as many resources as its wants. I was thinking in terms of implementation since a service is instantiated,
          Message 4 of 19 , Jan 3, 2007
          • 0 Attachment
            Benjamin Carlyle wrote:

            > * In REST it is likely that multiple resources will be served from a
            > single defined set of state, ie a service. For example an object or a
            > set of objects are likely to have several resources associated with
            > them
            > that act as the network interface to these objects. I would suggest
            > that
            > instead of "Each Dream service (being) a resource", each dream service
            > should make a set of resources available.

            You're absolutely right: a service can provide as many resources as
            its wants. I was thinking in terms of implementation since a service
            is instantiated, but that was wrong for this context. I've made note
            of it on the feedback page.

            > * Returning a dream blueprint to users of the system doesn't read
            > to me
            > as useful. If the blueprint exposure is an internal deployment
            > mechanism, this is ok. The blueprint appears to be an internal
            > document
            > that allows particular methods on particular resources to be mapped to
            > other method invocations on internally-defined objects. This is fine,
            > but should not normally be communicated to users of the interface.
            > Users
            > should see published lists of URIs that meet particular
            > requirements the
            > uses may have. Perhaps a cut-down form of the blueprint would be more
            > appropriate than one that exposes internal classes and the like.

            The blueprint is used by the framework to instantiate the service.
            So, the primary consumer of the blueprint is the framework. However,
            it's also used by /@inspect to return a HTML document about the
            service and its features. This human-readable document makes it easy
            to learn about new services and also provides additional links to
            online documentation.

            > * It looks like access to HTML headers and the like may be limited.
            > Where is the url returned in a POST's Location header in
            > <http://doc.opengarden.org/Dream_SDK/Tutorials/Address_Book>?

            That sample was intended for simplicity, not completeness. The basic
            communication unit is a HTTP message containing the headers and
            body. Common headers such as ContentType, ContentLength, etc. are
            exposed as properties, but arbitrary headers can also be set via the
            Headers[ ] property.

            --------------
            Steve G. Bjorg
            http://www.mindtouch.com
            http://www.opengarden.org
          • Steve G. Bjorg
            ... framework? ... The first goal for Dream is to make it easier to associate code with REST concepts. Currently, we have nice pattern matching on HTTP
            Message 5 of 19 , Jan 3, 2007
            • 0 Attachment
              "Mike Schinkel" <mikeschinkel@...> wrote:
              >
              > Benjamin Carlyle wrote:
              > > On the whole the framework doesn't look particularly RESTful
              > > or non-RESTful. It would be up to a particular blueprint and
              > > implementation to conform or not conform to REST principles.
              > > If it is designed for interaction with HTTP and allows
              > > appropriate access to HTTP headers I don't see any obvious
              > > problems on the surface.
              >
              > I'm curious; could RESTfulness be more strongly enforced by the
              framework?
              >

              The first goal for Dream is to make it easier to associate code with
              REST concepts. Currently, we have nice pattern matching on HTTP
              methods and URIs, but still lack content-type matching. Well, 2 out
              of 3 is not a bad start.

              The unit of communication is messages, which contain a status code,
              headers, and a body. Messages are modeled after HTTP messages,
              although they are not tied to any specific implementation, making the
              Dream runtime more portable.

              Finally, RESTful design is promoted by providing guidelines (such as
              REST for the Rest of Us) and examples. The framework itself permits
              developers to implement non-RESTful services, just like an
              object-oriented language facilitates non object-oriented code. The
              question of restricting design freedom is a tough one. It seems that
              even the best arguments are met with unusual, but necessary exceptions
              to the rules.

              My ongoing goal for Dream will be to facilitate tapping in to the
              existing richness of HTTP and make it easier for developers to build
              applications with it.


              Cheers,

              - Steve

              --------------
              Steve G. Bjorg
              http://www.mindtouch.com
              http://www.opengarden.org
            Your message has been successfully submitted and would be delivered to recipients shortly.