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

Dreams about ReSTifying web apps

Expand Messages
  • toydi
    Recently I dreamed about a *web utopia*. In this *utopia*, all kinds of today s killer web apps (i.e. forum, wiki, cms, portals, weblog etc) have adopted ReST
    Message 1 of 30 , Oct 14, 2005
    • 0 Attachment
      Recently I dreamed about a *web utopia*.

      In this *utopia*, all kinds of today's killer web apps (i.e. forum,
      wiki, cms, portals, weblog etc) have adopted ReST and started to form
      a wonderful scene: they are able to integrate each others
      functionality, exchanging information among themselves seamlessly and
      even happily inviting desktop & mobile apps to join in their big
      family.

      (Is it possible in reality? Dream is dream.. )

      Another night, I dreamed again, about the early stage of *utopia*. I
      saw developers are using a kind of method to model and identify
      resources for each web apps.

      Next, they use a kind of _common_description_language_ to describe
      each resource, to record their characteristics (i.e. which request
      they process, what representation they accept & return).

      They even record relationships between resources (i.e. resource A
      creates resource B), allow new resources derived from current
      resources, and even support versioning in resource description.

      The same time, I saw developers have already identified a list of
      _essential_needs_ in order to adopt ReST style in apps. Based on the
      list, they start to build _application_ frameworks_ in different
      languages, creating _stardard_libraries_ and porting to each
      languages.

      Using the frameworks & libraries, they start to select resources
      needed for their application from a resource description list and turn
      each resource into binaries. Rather than re-write the codes, they also
      reuse the available resource binaries.

      And i saw, more and more open communities are rapidly publishing
      resource packages for particular web apps. Developers will choose
      resources they need and assemble them into their apps. Rather than
      maintain their own resources, some apps decide to simply subscribe
      other apps' resources via web...guess what, i even saw IDE toolkits
      available!

      (am i too naive to believe this day will come?)

      In a sudden, I woke up and immediately, I ask myself, was that a dream?
      I crawled back to my desk, booted up my old p3 box, googled a quoted
      string "restful web utopia".

      Google replied:
      Your search - "restful web utopia" - did not match any documents.


      --
      -toydi-
    • Andrzej Jan Taramina
      ... I ld like to have some of what you took before going to sleep! Nice trip! ;-) Andrzej Jan Taramina Chaeron Corporation: Enterprise System Solutions
      Message 2 of 30 , Oct 14, 2005
      • 0 Attachment
        toydi dreamed:

        > In this *utopia*, all kinds of today's killer web apps (i.e. forum,
        > wiki, cms, portals, weblog etc) have adopted ReST and started to form a
        > wonderful scene: they are able to integrate each others functionality,
        > exchanging information among themselves seamlessly and even happily
        > inviting desktop & mobile apps to join in their big family.

        I'ld like to have some of what you took before going to sleep! Nice trip!
        ;-)


        Andrzej Jan Taramina
        Chaeron Corporation: Enterprise System Solutions
        http://www.chaeron.com
      • Laurian Gridinoc
        Hello, I think a RESTful Design Patterns book/wiki may make a step in this direction, imagine a place where you may find all the killer webapps you named it,
        Message 3 of 30 , Oct 15, 2005
        • 0 Attachment
          Hello,

          I think a "RESTful Design Patterns" book/wiki may make a step in this direction, imagine a place where you may find all the killer webapps you named it, restified, analysed, and their interoperability demonstrated.

          Upon such community discussed and agreed patterns, interoperable APIs will spawn easily.

          Cheers,
          Laurian Gridinoc

          On 10/14/05, toydi <iamstupidiot@...> wrote:
          Recently I dreamed about a *web utopia*.

          In this *utopia*, all kinds of today's killer web apps (i.e. forum,
          wiki, cms, portals, weblog etc) have adopted ReST and started to form
          a wonderful scene: they are able to integrate each others
          functionality, exchanging information among themselves seamlessly and
          even happily inviting desktop & mobile apps to join in their big
          family.

          (Is it possible in reality? Dream is dream.. )

          Another night, I dreamed again, about the early stage of *utopia*. I
          saw developers are using a kind of method to model and identify
          resources for each web apps.

          Next, they use a kind of _common_description_language_ to describe
          each resource, to record their characteristics ( i.e. which request
          they process, what representation they accept & return).

          They even record relationships between resources (i.e. resource A
          creates resource B), allow new resources derived from current
          resources, and even support versioning in resource description.

          The same time, I saw developers have already identified a list of
          _essential_needs_ in order to adopt ReST style in apps. Based on the
          list, they start to build _application_ frameworks_ in different
          languages, creating _stardard_libraries_ and porting to each
          languages.

          Using the frameworks & libraries, they start to select resources
          needed for their application from a resource description list and turn
          each resource into binaries. Rather than re-write the codes, they also
          reuse the available resource binaries.

          And i saw, more and more open communities are rapidly publishing
          resource packages for particular web apps. Developers will choose
          resources they need and assemble them into their apps. Rather than
          maintain their own resources, some apps decide to simply subscribe
          other apps' resources via web...guess what, i even saw IDE toolkits
          available!

          (am i too naive to believe this day will come?)

          In a sudden, I woke up and immediately, I ask myself, was that a dream?
          I crawled back to my desk, booted up my old p3 box, googled a quoted
          string "restful web utopia".

          Google replied:
          Your search - "restful web utopia" - did not match any documents.


          --
          -toydi-
        • toydi
          ... here s some more organized thoughts about the *dream* ;) 1) Find a good way to analyze, model, describe & discuss Resources Rather than looking an
          Message 4 of 30 , Oct 15, 2005
          • 0 Attachment
            On 10/15/05, Laurian Gridinoc <laurian@...> wrote:

            > I think a "RESTful Design Patterns" book/wiki may make a step in this
            > direction, imagine a place where you may find all the killer webapps you
            > named it, restified, analysed, and their interoperability demonstrated.
            >
            > Upon such community discussed and agreed patterns, interoperable APIs will
            > spawn easily.

            here's some more organized thoughts about the *dream* ;)

            1) Find a good way to analyze, model, describe & discuss Resources

            Rather than looking an application as a whole, will it be better to
            break it down into atomical resources, which only represent each
            single functionality? (i.e. in a forum app, we have "Forum" resource,
            "Thread" resource & "User" resource)

            Resource looks quite object-oriented, will it be efficient to just use
            object-oriented techniques & tools (i.e. UML) in order to figure out
            all needed resources for each app?

            How are we going to describe these resources to allow further
            discussion between community? What we need to describe? (resource's
            characteristic, relationship between resources, version of resource?)
            What we use to describe, and how? (RDF, WSDL, TopicMap? and agree with
            a standard describing convention?).


            2) Figure out basic needs to build ReSTful apps

            Which part of codes that we repeat in every restful web app? (URL
            Mapper, Resource Manager, HTTP Authentication, HTTP Cache, URL
            Parser?)

            Build (or reuse any?) a API library to handle HTTP (Cache,
            Authentication, ConNeg, URL Parser, Request & Response etc)?

            Analyze and list out what essential things needed in a ReSTful
            application framework, next build frameworks for different platforms
            (or reuse current frameworks?)


            3) Start to build and run ReSTful apps in Web

            Will it be nice to start with building some killer web apps, to allow
            ourselves to experience & understand what's the real benefits of
            adopting ReST? to figure out what we missed and things to fix in (1)
            and (2).

            Is it possible to see an app as a collection of resources rather than
            a whole? And we can always remove them or reassemble them to customize
            our app.


            4) Is this a right direction to start?

            If yes, where to start, when to start, who will join?
            If no, any suggestions? :-)

            It's just a *utopia*, and I think it has been re-appearing in ppl's
            dreams long before CORBA, RMI, and ReST... and it will keeps repeating
            in future. A dream of no barrier in communications (the babel tower?)

            Cheers, :-)

            --
            -toydi-
          • toydi
            ... Hi, i tried jrest.ontoware.org, but seems like it s not started yet? I ve been thinking about the *web utopia* again. During a conversation with a friend,
            Message 5 of 30 , Oct 20, 2005
            • 0 Attachment
              On 10/16/05, xamde666 <spam@...> wrote:
              > --- In rest-discuss@yahoogroups.com, toydi <iamstupidiot@g...> wrote:
              > >
              > > Recently I dreamed about a *web utopia*.
              >
              > Let's do what you describe. I am thinking hard about a library for
              > java, first results are at jrest.ontoware.org. But I realise, we need
              > a programming language independent approach. Let's use 'xrest.org' to
              > promote a RESTful alternative to XML-RPC. It should be easier to use
              > xREST. Tough goal.
              >
              > Kind regards,
              >
              > Max

              Hi, i tried jrest.ontoware.org, but seems like it's not started yet?

              I've been thinking about the *web utopia* again. During a conversation
              with a friend, we talked about REST. His view is: REST is about
              enforcing software engineering discipline into application
              developement, restricting the way we think and design app
              architecture. He feels that people will turn away from software
              discipline if it's too strict, as everyone prefer to do things in
              their own way.

              It makes me feel that web utopia will remain utopia, if the goal is to
              create a standard that restrict people to follow certain set of rules
              or telling them to give up the way they code their apps.

              Is that the reason behind why people prefer CORBA, SOAP when they talk
              about intergration and interoperability between applications?

              This leads me to re-think whether to start restifying current killer
              web apps is a right move?
              --
              -toydi-
            • Bob Haugen
              ... Do you think that CORBA and SOAP do not require people to follow a set of rules? Do you think those rules are simpler and easier than REST? The great
              Message 6 of 30 , Oct 20, 2005
              • 0 Attachment
                On 10/20/05, toydi <iamstupidiot@...> wrote:
                > It makes me feel that web utopia will remain utopia, if the goal is to
                > create a standard that restrict people to follow certain set of rules
                > or telling them to give up the way they code their apps.
                >
                > Is that the reason behind why people prefer CORBA, SOAP when they talk
                > about intergration and interoperability between applications?

                Do you think that CORBA and SOAP do not require people to follow a set of rules?
                Do you think those rules are simpler and easier than REST?

                The great majority of users of Amazon's Web services found REST easier
                than SOAP.
              • Jan Algermissen
                ... The Web exists and you experience the benefits of its architecture over and over again every day; but we usually take them for granted and thus do not
                Message 7 of 30 , Oct 20, 2005
                • 0 Attachment
                  On Oct 20, 2005, at 3:04 PM, toydi wrote:

                  > It makes me feel that web utopia will remain utopia,

                  The Web exists and you experience the benefits of its architecture
                  over and over again every day; but we usually take them for granted
                  and thus do not notice them anymore. Example: Google or Amazon or
                  ebay can change the state machines that make up their Web
                  applications in any way they want without causing any problems for
                  you to keep using them.

                  > if the goal is to
                  > create a standard that restrict people to follow certain set of rules
                  > or telling them to give up the way they code their apps.

                  The goal (of REST) is to provide a set of constraints *and* a
                  detailed analysis of the benefits you get when following these
                  constraints. Following architectural styles enables you to reason
                  about the properties the system you build will have.

                  Jan

                  ________________________________________________________________________
                  _______________
                  Jan Algermissen, Consultant & Programmer
                  http://jalgermissen.com
                  Tugboat Consulting, 'Applying Web technology to enterprise IT'
                  http://www.tugboat.de
                • toydi
                  ... That s a good sign indeed. :) I always feel that ReST provides a more *natural* way to see things in a distributed web environment. My concern is how to
                  Message 8 of 30 , Oct 20, 2005
                  • 0 Attachment
                    On 10/20/05, Bob Haugen <bob.haugen@...> wrote:

                    > Do you think that CORBA and SOAP do not require people to follow a set of rules?
                    > Do you think those rules are simpler and easier than REST?
                    >
                    > The great majority of users of Amazon's Web services found REST easier
                    > than SOAP.

                    That's a good sign indeed. :)

                    I always feel that ReST provides a more *natural* way to see things in
                    a distributed web environment. My concern is how to encourage more
                    developers to start to restify their web apps, in order to create a
                    major interoperable web environment.

                    Is it a right move to start to work on *more concrete* practical
                    guidelines, toolkit, frameworks, to provide developers a clear path on
                    how to restify their apps start from analysis and design phase til the
                    implementation. Or is it better to just leave developers to figure out
                    things in their own way?

                    The point in my previous message is, if we work on these guidelines
                    and framework, how to balance between "developers need to change a
                    lot" and "developers still flexible to do things their own way". How
                    to balance so that guidelines will not become a strict standard, but
                    still provide a common understanding platform to allow further
                    discussion and developement.

                    (Recently, I'm thinking whether it's the right time to work on
                    practical guidelines and toolkit for ReST app development start from
                    analysis phase to implementation. Hopefully it will not try to
                    reinvent the whole wheel cycle, but rather to analyze the essential
                    needs in ReST app developement, then firgure out how to reuse
                    available tools and resources.)


                    --
                    -toydi-
                  • Dr. Ernie Prabhakar
                    Hi toydi, I m new to the list, so forgive my jumping in, but I ve been thinking ... I worry about this question a lot; have you read any Clay Christensen or
                    Message 9 of 30 , Oct 21, 2005
                    • 0 Attachment
                      Hi toydi,

                      I'm new to the list, so forgive my jumping in, but I've been thinking
                      about this very question:

                      > My concern is how to encourage more
                      > developers to start to restify their web apps, in order to create a
                      > major interoperable web environment.

                      I worry about this question a lot; have you read any Clay Christensen
                      or Seth Godin? They both (in different ways) tackle the problem of
                      how do you get a community/ecosystem to change the way they think
                      about a problem...

                      > Is it a right move to start to work on *more concrete* practical
                      > guidelines, toolkit, frameworks, to provide developers a clear path on
                      > how to restify their apps start from analysis and design phase til the
                      > implementation. Or is it better to just leave developers to figure out
                      > things in their own way?

                      Like they say, I believe the right solution is to "think globally,
                      act locally." :-) The 'right' answer to your question depends on
                      the optimal match between your resources (skills, contacts,
                      reputation, passion) and the communities needs. I suspect all of us
                      here believe that "REST" is the answer -- we're just trying to find
                      the question. :-) The challenge, in other words, is identifying what
                      the actual barriers are that prevent/discourage people from adopting
                      REST, and we each individually can do within our own trust networks.

                      To your particular question, I believe the optimal approach is to be
                      "exemplary" rather than "normative." That is, rather than trying to
                      say, "You -should- do it this way," we demonstrate the virtue of REST
                      by saying, "This is how *I* do it, which is really easy for you to
                      adopt." We don't try to enforce consistency -- we merely make it the
                      path of least resistance!

                      For example, one idea I've been toying with is creating a
                      "rest_scaffold" that would make it trivial to RESTify "Ruby on
                      Rails". As a bonus, it would use XHTML as the encoding so that the
                      same app could be used with: i) web browsers, ii) web services, and
                      iii) AJAX. I suspect something like this would simultaneously lower
                      barriers to entry and create a compelling value proposition -- both
                      of which are essential for adoption.

                      Does that make sense?

                      See my blog (below) for more details.

                      Best,
                      -- Ernie P.

                      On Oct 20, 2005, at 5:00 PM, toydi wrote:

                      > On 10/20/05, Bob Haugen <bob.haugen@...> wrote:
                      >
                      > > Do you think that CORBA and SOAP do not require people to follow
                      > a set of rules?
                      > > Do you think those rules are simpler and easier than REST?
                      > >
                      > > The great majority of users of Amazon's Web services found REST
                      > easier
                      > > than SOAP.
                      >
                      > That's a good sign indeed. :)
                      >
                      > I always feel that ReST provides a more *natural* way to see things in
                      > a distributed web environment. My concern is how to encourage more
                      > developers to start to restify their web apps, in order to create a
                      > major interoperable web environment.
                      >
                      > Is it a right move to start to work on *more concrete* practical
                      > guidelines, toolkit, frameworks, to provide developers a clear path on
                      > how to restify their apps start from analysis and design phase til the
                      > implementation. Or is it better to just leave developers to figure out
                      > things in their own way?
                      >
                      > The point in my previous message is, if we work on these guidelines
                      > and framework, how to balance between "developers need to change a
                      > lot" and "developers still flexible to do things their own way". How
                      > to balance so that guidelines will not become a strict standard, but
                      > still provide a common understanding platform to allow further
                      > discussion and developement.
                      >
                      > (Recently, I'm thinking whether it's the right time to work on
                      > practical guidelines and toolkit for ReST app development start from
                      > analysis phase to implementation. Hopefully it will not try to
                      > reinvent the whole wheel cycle, but rather to analyze the essential
                      > needs in ReST app developement, then firgure out how to reuse
                      > available tools and resources.)

                      ------------
                      Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
                      Ex-Physicist, Marketing Weenie, and Dilettante Hacker
                      Probe-Hacker blog: http://www.opendarwin.org/~drernie/
                    • toydi
                      ... What are your worries? :-) ... Indeed, it s easier, more *persuasive* and directly serve the needs of a particular community. I m just a newbie and I think
                      Message 10 of 30 , Oct 21, 2005
                      • 0 Attachment
                        On 10/22/05, Dr. Ernie Prabhakar <drernie@...> wrote:

                        > I worry about this question a lot;

                        What are your worries? :-)

                        > To your particular question, I believe the optimal approach is to be
                        > "exemplary" rather than "normative."

                        Indeed, it's easier, more *persuasive* and directly serve the needs of
                        a particular community. I'm just a newbie and I think there are still
                        many questions in my mind, awaiting for answers. :-) It's a pleasant
                        experience to learn in a discussion group.

                        > For example, one idea I've been toying with is creating a
                        > "rest_scaffold" that would make it trivial to RESTify "Ruby on
                        > Rails".

                        Thanks for the link, it's interesting!

                        http://www.opendarwin.org/~drernie/rest-enabled-xhtml-20051019.html


                        It seems like there are more *RESTified toys* is available now. ;-)

                        --
                        -toydi-
                      • Dr. Ernie Prabhakar
                        Hi Toydi, ... Well, since you asked... I like REST -- it feels very *right*. However, even though vastly simpler than XML-RPC, it still feels too
                        Message 11 of 30 , Oct 21, 2005
                        • 0 Attachment
                          Hi Toydi,

                          On Oct 21, 2005, at 5:39 PM, toydi wrote:

                          >> I worry about this question a lot;
                          >
                          > What are your worries? :-)

                          Well, since you asked...

                          I like REST -- it feels very *right*. However, even though vastly
                          simpler than XML-RPC, it still feels too "unconstrained" for a
                          dilettante like me to make intelligent decision decisions. The
                          purpose of that preso you cited:

                          REX: REST-Enabled XHTML
                          http://www.opendarwin.org/~drernie/rest-enabled-xhtml-20051019.html

                          is to try to define a simpler "profile" for using REST in the context
                          of dual-use XHTML (for both web pages and web services). The
                          ultimate goal is to character something that is simultaneously:
                          a) simple enough to be easily learnable/implementable
                          b) functional enough to solve lots of real-world problems
                          c) "RESTy" enough to encourage good design behavior.

                          Roy himself was kind enough to provide some comments, but I would
                          love to get feedback from others on this list about whether I am in
                          fact meeting those goals, or how I could do better. Plus, I'm still
                          figuring out how to best explain this idea, so suggestions for how to
                          clarify my presentation are also welcome.

                          Thanks,
                          - Ernie P.
                          ------------
                          Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
                          Ex-Physicist, Marketing Weenie, and Dilettante Hacker
                          Probe-Hacker blog: http://www.opendarwin.org/~drernie/
                        • toydi
                          Hi, I just wrote a powerpoint slide about a dream about web utopia , about a utopia where various apps able to interact seamlessly via a distributed web
                          Message 12 of 30 , Oct 28, 2005
                          • 0 Attachment
                            Hi, I just wrote a powerpoint slide about a dream about "web utopia",
                            about a utopia where various apps able to interact seamlessly via a
                            distributed web environment.

                            http://restylab.php5.cz/files/webutopia.ppt

                            It's still a very *roughly dafted* idea, but anyway, I'm looking
                            forward to receive feedbacks and comments about the idea, to point out
                            any mistakes, and add in more brainstorming ideas. :-)


                            Cheers :-)

                            --
                            -toydi-
                          • Dr. Ernie Prabhakar
                            Hi Toydi, Thanks, very interesting. My initial reactions: a) Yes, absolutely. This is how the world *should* work, and I don t see a good reason it cannot. b)
                            Message 13 of 30 , Oct 28, 2005
                            • 0 Attachment
                              Hi Toydi,

                              Thanks, very interesting. My initial reactions:

                              a) Yes, absolutely. This is how the world *should* work, and I don't
                              see a good reason it cannot.

                              b) Stop trying to standardize object models. I realize that may be
                              heresy -- I'm a long time OO guy -- but I think objects are just too
                              hard to manage in a large community. Instead, standardize *tables*.
                              That is, formalize the *data* not the *methods.* That's more RESTy
                              anyway.

                              c) Microformats (semantic XHTML) as the optimal lingua france for
                              data encoding. Among many advantages: you don't need to design Yet
                              Another XML Schema for your web interface. Let's be honest: how
                              many people do*you* know who can do that properly?

                              For the record (and anyone who cares), I've created a new section on
                              the Microformats wiki to track this topic:

                              http://microformats.org/wiki/rest

                              I'll also be discussing this, and related topics, on the new
                              micrformats-rest mailing list:

                              http://microformats.org/discuss/mail/microformats-rest/

                              I will try to stay active on this list for specific REST-related
                              questions, but I'll be discussing more concrete implementations over
                              there. Feel free to come join toydi and I there!

                              Best,
                              Ernie P.


                              On Oct 28, 2005, at 9:02 AM, toydi wrote:

                              > Hi, I just wrote a powerpoint slide about a dream about "web utopia",
                              > about a utopia where various apps able to interact seamlessly via a
                              > distributed web environment.
                              >
                              > http://restylab.php5.cz/files/webutopia.ppt
                              >
                              > It's still a very *roughly dafted* idea, but anyway, I'm looking
                              > forward to receive feedbacks and comments about the idea, to point out
                              > any mistakes, and add in more brainstorming ideas. :-)
                              >
                              >
                              > Cheers :-)
                              >
                              > --
                              > -toydi-

                              ------------
                              Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
                              Ex-Physicist, Marketing Weenie, and Dilettante Hacker
                              Probe-Hacker blog: http://www.opendarwin.org/~drernie/
                            • toydi
                              Hi all, I would like to share some of my experience regarding browser s limitations. ... [Case] I built a simple web app recently in order to gain some REST
                              Message 14 of 30 , Oct 31, 2005
                              • 0 Attachment
                                Hi all, I would like to share some of my experience regarding
                                browser's limitations.

                                This message is somehow a response to REX proposal [1] :
                                > 1. Constraining REST verbs to POST/GET

                                [Case]
                                I built a simple web app recently in order to gain some REST
                                experiences. The app's main target user agent is browser, and I faced
                                two problems:

                                1) To send out HTTP requests other than GET, POST, script
                                (xmlhttprequest) is the only solution. What if some end-users fail to
                                turn on the scripting support in their browsers?

                                2) Some browsers still having problems to correctly send out desired
                                HTTP request (e.g Opera8 can't send out PUT, DELETE, IE6 having
                                problem to send out DELETE to URL which require HTTP-digest-auth).

                                [Problems]
                                My web app need to provide services: 1) friendly enough for both
                                script-enabled and script-disabled browsers, 2) and also *rich
                                semantic* enough for other *powerful* user agents.

                                [Solution]
                                As a results, I try to make use of the "client-server" constraint [2]
                                to come out with a solution by separating out UI from the app's main
                                functionality.

                                "App functionality resources" accept complete HTTP requests (e.g GET,
                                PUT, POST, DELETE) to allow usual RESTful manipulation of resources.

                                "UI resources" (just some HTML Form pages) armed with scripts, allow
                                end-user to send out HTTP request directly to any "App functionality
                                resources".

                                In addition, the "UI resource" itself, also accepts POST request (in
                                case script failed), uses the received form-data to reconstruct an
                                internal request, then internally forwards it to the target "App
                                functionality resource".

                                [Example]
                                Well, here's some pictures (I always prefer pictures ;-) ) to show an
                                example on how to update an Announcement resource in my app:

                                Script-Enabled Scenario
                                (http://restylab.php5.cz/files/images/script-enabled-scenario.gif)
                                Script-Disabled Scenario
                                (http://restylab.php5.cz/files/images/script-disabled-scenario.gif)

                                With the separation of UI and functionality resources, the app now,
                                can serve well to various user agents including both script-enabled &
                                script-disabled browsers.

                                Any comments?

                                [1] http://www.opendarwin.org/~drernie/rest-enabled-xhtml-20051019.html
                                [] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_2

                                Cheers,
                                --
                                -toydi-
                              • Laurian Gridinoc
                                Hello, ... Or just POST to the `Announce with an extra ugly (hidden) parameter like http-equiv=PUT, and in your webapplication you have a request filter that
                                Message 15 of 30 , Nov 1, 2005
                                • 0 Attachment
                                  Hello,

                                  On 11/1/05, toydi <iamstupidiot@...> wrote:
                                  > [Example]
                                  > Well, here's some pictures (I always prefer pictures ;-) ) to show an
                                  > example on how to update an Announcement resource in my app:
                                  > Script-Enabled Scenario
                                  > (http://restylab.php5.cz/files/images/script-enabled-scenario.gif)
                                  > Script-Disabled Scenario
                                  > (http://restylab.php5.cz/files/images/script-disabled-scenario.gif)
                                  > With the separation of UI and functionality resources, the app now,
                                  > can serve well to various user agents including both script-enabled &
                                  > script-disabled browsers.
                                  > Any comments?

                                  Or just POST to the `Announce' with an extra ugly (hidden) parameter
                                  like http-equiv=PUT, and in your webapplication you have a request
                                  filter that detects this parameter, and change the verb to PUT before
                                  reaching `Announce'.
                                  So, you may free the EditAnnounceForm of a POST handler.

                                  Cheers,
                                  --
                                  Laurian Gridinoc, www.grapefruit.ro
                                • toydi
                                  Hi Laurian, ... That would be a nice design decision too. :-) The reason behind why I use an EditAnnounceForm resource, is that, Announce resource itself just
                                  Message 16 of 30 , Nov 1, 2005
                                  • 0 Attachment
                                    Hi Laurian,

                                    On 11/1/05, Laurian Gridinoc <laurian@...> wrote:

                                    > Or just POST to the `Announce' with an extra ugly (hidden) parameter
                                    > like http-equiv=PUT, and in your webapplication you have a request
                                    > filter that detects this parameter, and change the verb to PUT before
                                    > reaching `Announce'.
                                    > So, you may free the EditAnnounceForm of a POST handler.
                                    >

                                    That would be a nice design decision too. :-)

                                    The reason behind why I use an EditAnnounceForm resource, is that,

                                    Announce resource itself just nice enough, to serve normal restful
                                    interactions by accepting GET, PUT, DELETE requests. I try to keep it
                                    simple and separate it away from UI requirements.

                                    OTOH, EditAnnounceForm is actually a "read-only resource" [1] (accept
                                    GET only) that provides UI (buttons, a HTML form and a client-script)
                                    to help end users sending out HTTP request to Announce resource.

                                    In order to support some older browsers, EditAnnounceForm can also
                                    acts as a "processing resource" [1] to accept and process POST
                                    request.

                                    As you said, certain hidden parameters are included in the POST
                                    request, so that EditAnnounceForm can detect and reconstruct them into
                                    a PUT request and forward to Announce resource. What i did, is using a
                                    submit & a hidden <input> in the form:

                                    <form method="post">
                                    ....
                                    <input type="hidden" name="actionuri" value="/announcement/12" />
                                    <input type="submit" name="reqmethod" value="update" />
                                    </form>

                                    EditAnnounceForm will reconstruct the POST request into an internal
                                    PUT request if reqmethod == "update" and send it to "/announcement/12"
                                    (an Announce resource).

                                    Again, why I choose to use this design is first, I can take away UI
                                    codes if not needed anymore. Or, I only need to change codes in
                                    EditAnnounceForm, if the UI is changed (maybe using a new XForm).
                                    Announce resource is always there, I don't have to touch it.

                                    Again, it's only a design decision. So, is there any "not so good
                                    practice" in this design method? :-)


                                    [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt

                                    Cheers,
                                    --
                                    -toydi-
                                  • Laurian Gridinoc
                                    Hello, ... I propose http://www.grapefruit.ro/script-disabled-scenario.gif You have in your form a hidden parameter let s say named http-equiv with the value
                                    Message 17 of 30 , Nov 1, 2005
                                    • 0 Attachment
                                      Hello,

                                      On 11/1/05, toydi <iamstupidiot@...> wrote:
                                      > > Or just POST to the `Announce' with an extra ugly (hidden) parameter
                                      > > like http-equiv=PUT, and in your webapplication you have a request
                                      > > filter that detects this parameter, and change the verb to PUT before
                                      > > reaching `Announce'.
                                      > > So, you may free the EditAnnounceForm of a POST handler.
                                      > >
                                      > That would be a nice design decision too. :-)
                                      > The reason behind why I use an EditAnnounceForm resource, is that,
                                      > Announce resource itself just nice enough, to serve normal restful
                                      > interactions by accepting GET, PUT, DELETE requests. I try to keep it
                                      > simple and separate it away from UI requirements.
                                      > OTOH, EditAnnounceForm is actually a "read-only resource" [1] (accept
                                      > GET only) that provides UI (buttons, a HTML form and a client-script)
                                      > to help end users sending out HTTP request to Announce resource.
                                      > In order to support some older browsers, EditAnnounceForm can also
                                      > acts as a "processing resource" [1] to accept and process POST
                                      > request.
                                      > As you said, certain hidden parameters are included in the POST
                                      > request, so that EditAnnounceForm can detect and reconstruct them into
                                      > a PUT request and forward to Announce resource. What i did, is using a
                                      > submit & a hidden <input> in the form:
                                      > <form method="post">
                                      > ....
                                      > <input type="hidden" name="actionuri" value="/announcement/12" />
                                      > <input type="submit" name="reqmethod" value="update" />
                                      > </form>
                                      > EditAnnounceForm will reconstruct the POST request into an internal
                                      > PUT request if reqmethod == "update" and send it to "/announcement/12"
                                      > (an Announce resource).
                                      > Again, why I choose to use this design is first, I can take away UI
                                      > codes if not needed anymore. Or, I only need to change codes in
                                      > EditAnnounceForm, if the UI is changed (maybe using a new XForm).
                                      > Announce resource is always there, I don't have to touch it.
                                      > Again, it's only a design decision. So, is there any "not so good
                                      > practice" in this design method? :-)
                                      > [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt

                                      For the options:
                                      > Script-Enabled Scenario
                                      > (http://restylab.php5.cz/files/images/script-enabled-scenario.gif)
                                      > Script-Disabled Scenario
                                      > (http://restylab.php5.cz/files/images/script-disabled-scenario.gif)

                                      I propose
                                      http://www.grapefruit.ro/script-disabled-scenario.gif

                                      You have in your form a hidden parameter let's say named http-equiv
                                      with the value PUT,
                                      your app server has a filter that intercepts POST requests, and if a
                                      http-equiv param is present, it `rewrites' the request to have the
                                      verb specified in the parameter.

                                      So you just code your app using all HTTP verbs, and the filter takes
                                      care of the script-disables situation.

                                      Cheers,
                                      --
                                      Laurian Gridinoc, www.grapefruit.ro
                                    • Laurian Gridinoc
                                      ... I don t mean to say that you just change the HTTP header to express another verb, but to reconstruct the entire request accordingly. A PUT request will
                                      Message 18 of 30 , Nov 1, 2005
                                      • 0 Attachment
                                        On 11/1/05, Laurian Gridinoc <laurian@...> wrote:
                                        > For the options:
                                        > > Script-Enabled Scenario
                                        > > (http://restylab.php5.cz/files/images/script-enabled-scenario.gif)
                                        > > Script-Disabled Scenario
                                        > > (http://restylab.php5.cz/files/images/script-disabled-scenario.gif)
                                        >
                                        > I propose
                                        > http://www.grapefruit.ro/script-disabled-scenario.gif
                                        >
                                        > You have in your form a hidden parameter let's say named http-equiv
                                        > with the value PUT,
                                        > your app server has a filter that intercepts POST requests, and if a
                                        > http-equiv param is present, it `rewrites' the request to have the
                                        > verb specified in the parameter.
                                        > So you just code your app using all HTTP verbs, and the filter takes
                                        > care of the script-disables situation.

                                        I don't mean to say that you just change the HTTP header to express
                                        another verb, but to reconstruct the entire request accordingly.
                                        A PUT request will probably take it's body from another parameter.
                                        A DELETE request won't have a body at all.

                                        The idea is to keep the target URI to the Announce, and not re-route
                                        it through EditAnnounceForm.

                                        Cheers,
                                        --
                                        Laurian Gridinoc, www.grapefruit.ro
                                      • Dimitri Glazkov
                                        I think these are all great brainstorming thoughts. However, this more and more smells like tunnelling of verbs through nouns and thus less and less like rest.
                                        Message 19 of 30 , Nov 1, 2005
                                        • 0 Attachment
                                          I think these are all great brainstorming thoughts. However, this more
                                          and more smells like tunnelling of verbs through nouns and thus less
                                          and less like rest.

                                          If you don't have the ability to use PUT and DELETE from the client,
                                          then your only valid choice is to implement a server architecture that
                                          does not use them.

                                          Everything else, IMHO, is going to produce something that is neither
                                          RESTful nor useful.

                                          :DG<
                                        • toydi
                                          Hi Laurian, I think I got your idea. :-) Previously, I was using EditAnnounceForm as the *filter* in your proposal. I ll look deeper into this kind of design
                                          Message 20 of 30 , Nov 1, 2005
                                          • 0 Attachment
                                            Hi Laurian,

                                            I think I got your idea. :-) Previously, I was using EditAnnounceForm
                                            as the *filter* in your proposal. I'll look deeper into this kind of
                                            design in real-world implementation.


                                            Hi DG,

                                            On 11/1/05, Dimitri Glazkov <dimitri.glazkov@...> wrote:
                                            > I think these are all great brainstorming thoughts. However, this more
                                            > and more smells like tunnelling of verbs through nouns and thus less
                                            > and less like rest.
                                            >
                                            > If you don't have the ability to use PUT and DELETE from the client,
                                            > then your only valid choice is to implement a server architecture that
                                            > does not use them.
                                            >
                                            > Everything else, IMHO, is going to produce something that is neither
                                            > RESTful nor useful.

                                            The current HTML4 FORM element allows us to send out only GET or POST
                                            request. As a result, we try to use POST for resource manipulation
                                            purposes (e.g creation, update, deletion), as the GET should be always
                                            *safe*.

                                            However, our severs need to know whether an incoming POST is
                                            requesting for create, update or deletion? How to let servers know the
                                            request purpose? That's what we are discussing..

                                            When we have a RESful web service, supporting various powerful
                                            browsers and RESTful clients, and we still need to take care of some
                                            old browsers which support only GET & POST, rather than re-implement
                                            the whole web service, we are finding ways to allow old browsers to
                                            use our service without violating the Web nature.

                                            Somehow, we may see some resources as "processing resource" [1] to
                                            help us to process requests in POST, it's not trying to do tunnelling,
                                            but just to receive data needed to be processed.


                                            [1] http://www.markbaker.ca/2001/09/draft-baker-http-resource-state-model-01.txt
                                            (Section 3.1.4 Processing resources)

                                            Cheers,
                                            --
                                            -toydi-
                                          • Dimitri Glazkov
                                            ... I understand the challenge. It s the approach that I don t like :) ... That s what I am discussing, too. IMHO, once you have tunnelled delete and update
                                            Message 21 of 30 , Nov 1, 2005
                                            • 0 Attachment
                                              On 11/1/05, toydi <iamstupidiot@...> wrote:

                                              > The current HTML4 FORM element allows us to send out only GET or POST
                                              > request. As a result, we try to use POST for resource manipulation
                                              > purposes (e.g creation, update, deletion), as the GET should be always
                                              > *safe*.

                                              I understand the challenge. It's the approach that I don't like :)

                                              > However, our severs need to know whether an incoming POST is
                                              > requesting for create, update or deletion? How to let servers know the
                                              > request purpose? That's what we are discussing..

                                              That's what I am discussing, too. IMHO, once you have tunnelled delete
                                              and update through POST, you have effectively left the realm of REST.
                                              Your POST verb no longer means "create", and very little separates it
                                              from the XML-RPC crowd.

                                              What I am suggesting is instead focusing on server architectures that
                                              only have "retrieve" and "create" operations. I believe such
                                              architectures are not only possible, but can also fit naturally into
                                              the current Web.

                                              > When we have a RESful web service, supporting various powerful
                                              > browsers and RESTful clients, and we still need to take care of some
                                              > old browsers which support only GET & POST, rather than re-implement
                                              > the whole web service, we are finding ways to allow old browsers to
                                              > use our service without violating the Web nature.

                                              I understand what you're saying and agree with the notion. To nitpick
                                              just a little bit, since the "old browser" is the most commonly used
                                              and most accessible client over HTTP, defining it as "providing
                                              backward compatibility" seems like a fallacy. Maybe a better way to
                                              say it is "defining REST architectures that are valid for HTML user
                                              agents"?

                                              > Somehow, we may see some resources as "processing resource" [1] to
                                              > help us to process requests in POST, it's not trying to do tunnelling,
                                              > but just to receive data needed to be processed.

                                              That sounds like tunnelling to me. You are wrapping "delete" or
                                              "update" operation in a POST request. The processing resource model is
                                              valid, it's just the use of it is not.

                                              :DG<
                                            • Laurian Gridinoc
                                              Hello, ... Correct, but that little would be safe (GET) vs non-safe (POST which tunnels DELETE and PUT); which is a little better than regular web services
                                              Message 22 of 30 , Nov 1, 2005
                                              • 0 Attachment
                                                Hello,

                                                On 11/1/05, Dimitri Glazkov <dimitri.glazkov@...> wrote:
                                                > > The current HTML4 FORM element allows us to send out only GET or POST
                                                > > request. As a result, we try to use POST for resource manipulation
                                                > > purposes (e.g creation, update, deletion), as the GET should be always
                                                > > *safe*.
                                                >
                                                > I understand the challenge. It's the approach that I don't like :)
                                                >
                                                > > However, our severs need to know whether an incoming POST is
                                                > > requesting for create, update or deletion? How to let servers know the
                                                > > request purpose? That's what we are discussing..
                                                >
                                                > That's what I am discussing, too. IMHO, once you have tunnelled delete
                                                > and update through POST, you have effectively left the realm of REST.
                                                > Your POST verb no longer means "create", and very little separates it
                                                > from the XML-RPC crowd.

                                                Correct, but that 'little' would be safe (GET) vs non-safe (POST which
                                                tunnels DELETE and PUT); which is a little better than regular web
                                                services approach.

                                                > What I am suggesting is instead focusing on server architectures that
                                                > only have "retrieve" and "create" operations. I believe such
                                                > architectures are not only possible, but can also fit naturally into
                                                > the current Web.
                                                >
                                                > > When we have a RESful web service, supporting various powerful
                                                > > browsers and RESTful clients, and we still need to take care of some
                                                > > old browsers which support only GET & POST, rather than re-implement
                                                > > the whole web service, we are finding ways to allow old browsers to
                                                > > use our service without violating the Web nature.
                                                >
                                                > I understand what you're saying and agree with the notion. To nitpick
                                                > just a little bit, since the "old browser" is the most commonly used
                                                > and most accessible client over HTTP, defining it as "providing
                                                > backward compatibility" seems like a fallacy. Maybe a better way to
                                                > say it is "defining REST architectures that are valid for HTML user
                                                > agents"?
                                                >
                                                > > Somehow, we may see some resources as "processing resource" [1] to
                                                > > help us to process requests in POST, it's not trying to do tunnelling,
                                                > > but just to receive data needed to be processed.
                                                >
                                                > That sounds like tunnelling to me. You are wrapping "delete" or
                                                > "update" operation in a POST request. The processing resource model is
                                                > valid, it's just the use of it is not.

                                                In some applications, the backward compatibility may be important; the
                                                issues is how to provide an optional backward compatibility without
                                                breaking the design of the application.

                                                And tunneling DELETE and PUT through POST without altering the normal
                                                target URI -- as in the filter approach -- seems less intrusive in the
                                                application logic than tunneling verbs through nouns -- ie. providing
                                                separate URIs for PUT and DELETE where a POST will have PUT or DELETE
                                                meaning -- like in the POST to EditAnnounceForm in the example in
                                                discussion.

                                                I would setup in an application such a backward compatibility mode at
                                                least for debug purposes.

                                                Anyway tunneled PUT and DELETE requests through POST will be harder to
                                                control by a http aware firewall/proxy, in the filter approach where
                                                the target URI is the intended one, than in tunneling verbs through
                                                nouns, where you may filter URIs that represents PUT or DELETE entry
                                                points.

                                                Cheers,
                                                --
                                                Laurian Gridinoc, www.grapefruit.ro
                                              • toydi
                                                Hi Dimitri, ... I m not quite clear about server architectures that only have retrieve and create operations , would you like elaborate more (maybe using
                                                Message 23 of 30 , Nov 1, 2005
                                                • 0 Attachment
                                                  Hi Dimitri,

                                                  On 11/2/05, Dimitri Glazkov <dimitri.glazkov@...> wrote:
                                                  > What I am suggesting is instead focusing on server architectures that
                                                  > only have "retrieve" and "create" operations. I believe such
                                                  > architectures are not only possible, but can also fit naturally into
                                                  > the current Web.

                                                  I'm not quite clear about "server architectures that only have
                                                  "retrieve" and "create" operations", would you like elaborate more
                                                  (maybe using a toy example) about this server arch?

                                                  Or, do you mean like something described in
                                                  (http://www.opendarwin.org/~drernie/rest-enabled-xhtml-20051019.html#slide14)?

                                                  Yet, i still couldn't grab what does it mean by:

                                                  [in REX proposal: Challenge #2: Only Two Verbs]
                                                  "Don't overwrite documents; update version
                                                  POST child&key1=value1 => new child URI"



                                                  Cheers, :-)
                                                  --
                                                  -toydi-
                                                • Dr. Ernie Prabhakar
                                                  Hi all, ... A fascinating discussion, and something I worry about. I had a thought -- which I don t like, but seems like the least bad idea I ve seen. :-) I
                                                  Message 24 of 30 , Nov 1, 2005
                                                  • 0 Attachment
                                                    Hi all,

                                                    On Nov 1, 2005, at 1:46 PM, Laurian Gridinoc wrote:
                                                    > And tunneling DELETE and PUT through POST without altering the normal
                                                    > target URI -- as in the filter approach -- seems less intrusive in the
                                                    > application logic than tunneling verbs through nouns -- ie. providing
                                                    > separate URIs for PUT and DELETE where a POST will have PUT or DELETE
                                                    > meaning -- like in the POST to EditAnnounceForm in the example in
                                                    > discussion.

                                                    A fascinating discussion, and something I worry about.

                                                    I had a thought -- which I don't like, but seems like the least bad
                                                    idea I've seen. :-)

                                                    I appreciate that a REST URI is designed to represent a specific
                                                    resource:

                                                    http://host/root/uri/

                                                    I think I understand why this is important, and why it is Very Bad to
                                                    mix verbs in with nouns. I also agree that it is important to not
                                                    mix the document content (including query strings) with the URI proper.

                                                    However, at the same time, my understanding is that REST was designed
                                                    to represent the way the (normal) web already works today. And the
                                                    fact of the matter is that there's *lots* of websites that support
                                                    the equivalent of PUT and DELETE operations without actually using
                                                    them. While its nice to think this problem might be solved by new
                                                    browsers, that's not really a viable option in the short term.

                                                    One option -- which Dimitri is pushing -- is that we simply disallow
                                                    those operations. That is:

                                                    * we don't PUT complete objects; we POST a request asking for an
                                                    object to be created/updated (with appropriate versions)

                                                    * we don't DELETE objects; we POST an update to that object flagging
                                                    it for removal/hiding

                                                    I actually like this approach, as I think it does map onto many
                                                    current application models -- as well as being implemented with
                                                    current browsers -- and respects the original intent of REST. I
                                                    would certainly encourage people to adopt that approach wherever
                                                    possible.

                                                    However, I don't think it is possible to say *never* do those
                                                    thing. In fact, people do them all the time on the web today, and
                                                    we'll never get most of them to move those apps over to RESTful
                                                    versions if they have to give up important functionality. And -- at
                                                    least if you care about converging REST with the normal web -- i.e.,
                                                    making existing web apps behave in a more RESTful fashion-- we have
                                                    to do *something*. If so, what is the least obnoxious thing that can
                                                    be done?

                                                    My current best guess is that we should define a standard suffix for
                                                    "decorating" URIs to indicate non-traditional behaviors. My favorite
                                                    candidate for the delimeter is "@", since it is rare to find in HTTP
                                                    URLs, but easily encoded, a la:

                                                    http://host/root/uri/%40PUT
                                                    using mime/multipart
                                                    http://host/root/uri/%40DELETE
                                                    with no body

                                                    Is this ugly? Absolutely. But I honestly can't think of an easier-to-
                                                    implement solution that is at least comprehensible, and doesn't
                                                    require people to give up major portions of their existing technology.

                                                    Having already committed one heresy, let me go a step further. :-)

                                                    I know that a URI is intended to be one very specific object, and
                                                    that additional processing is supposed to be done by the client.
                                                    But in practice, we often want to provide standard variants of a
                                                    given document. Rather than again overloading that onto the query
                                                    string, I think this might be another appropriate use of the "URI
                                                    suffix."

                                                    http://host/root/uri/%40list
                                                    http://host/root/uri/%40table
                                                    http://host/root/uri/%40ajax

                                                    Is this REST? No, I'll admit it is not. However, I'm trying to be
                                                    as RESTful as I can given the problem I need to solve. Is there a
                                                    better way?

                                                    -- Ernie P.
                                                    ------------
                                                    Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
                                                    Ex-Physicist, Marketing Weenie, and Dilettante Hacker
                                                    Probe-Hacker blog: http://www.opendarwin.org/~drernie/
                                                  • Roy T. Fielding
                                                    ... REST is a style of interaction that produces certain properties that we want out of a system. The Web is an implementation, some of which is standardized
                                                    Message 25 of 30 , Nov 2, 2005
                                                    • 0 Attachment
                                                      On Nov 1, 2005, at 5:42 PM, Dr. Ernie Prabhakar wrote:

                                                      > However, at the same time, my understanding is that REST was designed
                                                      > to represent the way the (normal) web already works today. And the
                                                      > fact of the matter is that there's *lots* of websites that support
                                                      > the equivalent of PUT and DELETE operations without actually using
                                                      > them. While its nice to think this problem might be solved by new
                                                      > browsers, that's not really a viable option in the short term.

                                                      REST is a style of interaction that produces certain properties
                                                      that we want out of a system. The Web is an implementation, some
                                                      of which is standardized (the good stuff) and some of which was
                                                      hacked-in by folks who were just trying to make a customer happy.
                                                      We can't work around an architecture -- we leave it as soon as
                                                      the attempt is made. To work around browser bugs, just fix the
                                                      stupid bugs or use a better browser.

                                                      I am amazed by how few people bother to point out Apache httpd
                                                      bugs that interfere with REST, even when they know I can fix them
                                                      once I know they exist and why they need to change.

                                                      The only reason the browsers haven't been fixed is because the
                                                      people who want them fixed haven't tried. I've been too busy
                                                      and don't have a machine that will compile Firefox. If people
                                                      would spend less time trying to convince Web Services to do what
                                                      they don't want to do and more time simply helping Web browser
                                                      developers fix their bugs, maybe we could make some progress.

                                                      If someone here patches Firefox and Ernie applies some peer
                                                      pressure on Safari, I am quite certain that I can guilt the
                                                      MSIE developers into fixing it as well. Just come up with a
                                                      simple statement of what needs fixing and why.

                                                      ....Roy
                                                    • Dimitri Glazkov
                                                      ... These are not the browser bugs. These are spec limitations. HTML UAs only support two verbs, POST and GET, per HTML4 spec. The new WebForms 2.0 spec
                                                      Message 26 of 30 , Nov 2, 2005
                                                      • 0 Attachment
                                                        On 11/2/05, Roy T. Fielding <fielding@...> wrote:

                                                        > REST is a style of interaction that produces certain properties
                                                        > that we want out of a system. The Web is an implementation, some
                                                        > of which is standardized (the good stuff) and some of which was
                                                        > hacked-in by folks who were just trying to make a customer happy.
                                                        > We can't work around an architecture -- we leave it as soon as
                                                        > the attempt is made. To work around browser bugs, just fix the
                                                        > stupid bugs or use a better browser.

                                                        These are not the browser bugs. These are spec limitations. HTML UAs
                                                        only support two verbs, POST and GET, per HTML4 spec.

                                                        The new WebForms 2.0 spec extends it and allows using multiple verbs:

                                                        http://whatwg.org/specs/web-forms/current-work/#for-http

                                                        This spec is not part of W3C work, although W3C acknowledged it:

                                                        http://www.w3.org/Submission/2005/02/Comment

                                                        So far, only Opera has made first stab at implementing this spec
                                                        publicly available:

                                                        http://groups.google.com/group/opera.beta/msg/e6711a9a6f124d71?as_umsgid=qfafl1d6u03asrj87u3gudvegr6tif6orp@...

                                                        I am pretty sure Safari and Firefox will follow. AFAIK, there are no
                                                        plans to implement Web Forms 2.0 in MSIE natively, but there is an
                                                        effort to provide a JS-powered implementation:

                                                        http://dean.edwards.name/weblog/2005/05/wf2-ie/


                                                        :DG<
                                                      • Roy T. Fielding
                                                        ... The only reason the HTML4 spec has only two options available in that field is *because* of the browser bugs. W3C specs have no spine. ... Yep. ....Roy
                                                        Message 27 of 30 , Nov 2, 2005
                                                        • 0 Attachment
                                                          On Nov 2, 2005, at 6:31 AM, Dimitri Glazkov wrote:
                                                          > On 11/2/05, Roy T. Fielding <fielding@...> wrote:
                                                          >> REST is a style of interaction that produces certain properties
                                                          >> that we want out of a system. The Web is an implementation, some
                                                          >> of which is standardized (the good stuff) and some of which was
                                                          >> hacked-in by folks who were just trying to make a customer happy.
                                                          >> We can't work around an architecture -- we leave it as soon as
                                                          >> the attempt is made. To work around browser bugs, just fix the
                                                          >> stupid bugs or use a better browser.
                                                          >
                                                          > These are not the browser bugs. These are spec limitations. HTML UAs
                                                          > only support two verbs, POST and GET, per HTML4 spec.

                                                          The only reason the HTML4 spec has only two options available
                                                          in that field is *because* of the browser bugs. W3C specs have
                                                          no spine.

                                                          > The new WebForms 2.0 spec extends it and allows using multiple verbs:
                                                          >
                                                          > http://whatwg.org/specs/web-forms/current-work/#for-http

                                                          Yep.

                                                          ....Roy
                                                        • Dr. Ernie Prabhakar
                                                          Hi Roy, I m happy to help take this on. I don t think it will solve the whole problem (we have a lot of legacy browsers to deal with, after all), but it seems
                                                          Message 28 of 30 , Nov 2, 2005
                                                          • 0 Attachment
                                                            Hi Roy,

                                                            I'm happy to help take this on. I don't think it will solve the
                                                            whole problem (we have a lot of legacy browsers to deal with, after
                                                            all), but it seems worth doing.

                                                            On Nov 2, 2005, at 5:34 AM, Roy T. Fielding wrote:
                                                            > If someone here patches Firefox and Ernie applies some peer
                                                            > pressure on Safari, I am quite certain that I can guilt the
                                                            > MSIE developers into fixing it as well. Just come up with a
                                                            > simple statement of what needs fixing and why.

                                                            So, is the recommendation:

                                                            a) Allow "PUT" and "DELETE" in forms?
                                                            or
                                                            b) Adopt WebForms 2.0?

                                                            That is, it seems we need to clarify whether we're asking browser
                                                            makers to upgrade HTML4 to support HTTP, or adopt a new version of
                                                            HTML. If the latter, then I'd like to make sure we define it as
                                                            minimally as possible, so we don't take on too much.

                                                            -- Ernie P.

                                                            ------------
                                                            Ernest N. Prabhakar, Ph.D. <drernie at opendarwin.org>
                                                            Ex-Physicist, Marketing Weenie, and Dilettante Hacker
                                                            Probe-Hacker blog: http://www.opendarwin.org/~drernie/
                                                          • Yannick Loiseau
                                                            Hi, ... for Firefox, may be the easier way would be an extension, or even a GreaseMonkey script to implent at least subset of WebForm 2 (such as constraints
                                                            Message 29 of 30 , Nov 2, 2005
                                                            • 0 Attachment
                                                              Hi,

                                                              Dr. Ernie Prabhakar wrote:
                                                              > we have a lot of legacy browsers to deal with, after all

                                                              for Firefox, may be the easier way would be an extension, or even a
                                                              GreaseMonkey script to implent at least subset of WebForm 2
                                                              (such as constraints checking, HTTP methods using xmllHttp, and so on)
                                                              May be some project has already started in this way, don't know...
                                                            • Dimitri Glazkov
                                                              I think implementing the section 5.6.1 of Web Forms 2.0 would do nicely.
                                                              Message 30 of 30 , Nov 2, 2005
                                                              • 0 Attachment
                                                                I think implementing the section 5.6.1 of Web Forms 2.0 would do nicely.

                                                                :DG<
                                                              Your message has been successfully submitted and would be delivered to recipients shortly.