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

Re: REX (WAS: [rest-discuss] Dreams...)

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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.