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

Re: [rest-discuss] new wiki page: Http Methods Support

Expand Messages
  • Bill de hÓra
    ... Urrgghhh... Fwiw it s still a lot better that a recent and nasty hack I tried where DELETE and PUT were mapped onto URIs which is a complete mess. I know
    Message 1 of 11 , Sep 12, 2003
    • 0 Attachment
      Mark Baker wrote:

      > I'd still like to be able to use PUT and DELETE though. But doing
      > this in addition would seem to address the concerns of the folks who
      > are concerned about the lack of widespread support for PUT and
      > DELETE.

      Urrgghhh... Fwiw it's still a lot better that a recent and nasty
      hack I tried where DELETE and PUT were mapped onto URIs which is a
      complete mess.

      I know you said to me once that it's not a fundamental problem that
      HTML forms don't support DELETE and PUT. But the workarounds such as
      yours leaves me deeply unconvinced - I think the HTML designers and
      the W3C set a very bad precedent and a lot of the goofy thinking
      around SOAP uber POST can be seen as coming from that precedent.

      I'm working on a reliable delivery exchange over HTTP and I'm
      running into similar problems as CarrotVsOrange. My take on that
      debate is that RSS justifies using the full HTTP method set and
      working around is shortsighted - it's not just that current lack of
      widespread support for DELETE and PUT isn't a good technical
      argument, but for RSS it's a not a good expedient argument either,
      since RSS is not anywhere like as dependent on HTML forms or
      browsers as CGI type technology was.

      Bill de hÓra
    • Bill de hÓra
      ... I m not. This only works if the syntax is uniform as well. Otherwise we re in codec hell. Uniform syntax + semantics could work. Bill de hÓra
      Message 2 of 11 , Sep 12, 2003
      • 0 Attachment
        Mark Baker wrote:

        > BTW, I should also mention that I think that Tim's solution is
        > "good enough". Tunneling is bad, but tunneling uniform semantics
        > ("delete") makes it bearable. As long as PUT and DELETE are also
        > supported, I'm happy.

        I'm not. This only works if the syntax is uniform as well. Otherwise
        we're in codec hell. Uniform syntax + semantics could work.

        Bill de hÓra
      • Bill de hÓra
        ... Mark, True, but you only need extensions in this case to workaround the clients. The core problem is at the client, not HTTP, which has all the methods we
        Message 3 of 11 , Sep 12, 2003
        • 0 Attachment
          Mark Baker wrote:


          > There's a middle ground here. It's not perfectly RESTful, but is more
          > so than the everything-with-POST approach. And what's making it
          > unRESTful is HTTP's lack of mandatory extensions (at least I think
          > that's the only thing).

          Mark,

          True, but you only need extensions in this case to workaround the
          clients. The core problem is at the client, not HTTP, which has all
          the methods we need to get the job done already.

          Nonetheless, thanks for this. I'm going to have a crack at
          implementing it for that reliable exchange application I mentioned
          elsewhere, so I can the map application onto HTML forms.

          Bill de hÓra
        • sa3ruby
          Any thoughts on this: http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients ? - Sam Ruby
          Message 4 of 11 , Sep 12, 2003
          • 0 Attachment
          • bhaugen32
            ... Is that something you can discuss in more detail? For example, what do you mean by reliable delivery exchange ?
            Message 5 of 11 , Sep 12, 2003
            • 0 Attachment
              Bill de hÓra wrote:

              > I'm working on a reliable delivery exchange over HTTP and I'm
              > running into similar problems as CarrotVsOrange.

              Is that something you can discuss in more detail?
              For example, what do you mean by "reliable delivery exchange"?
            • Bill de hÓra
              ... It s a formalization of a problem I keep running into with WS and HTTP inter-administrative integrations. For my money, once you can reliably transfer
              Message 6 of 11 , Sep 12, 2003
              • 0 Attachment
                bhaugen32 wrote:
                > Bill de hÓra wrote:
                >
                >
                >>I'm working on a reliable delivery exchange over HTTP and I'm
                >>running into similar problems as CarrotVsOrange.
                >
                >
                > Is that something you can discuss in more detail?

                It's a formalization of a problem I keep running into with WS and
                HTTP inter-administrative integrations. For my money, once you can
                reliably transfer documents using client-server HTTP, a considerable
                number of unneccesary WS specs can be canned.


                > For example, what do you mean by "reliable delivery exchange"?

                Once and only once delivery, on a pure client-server HTTP model, no
                extensions a la WebDAV/HTTPR, based on the five packet handshake
                protocol (parties exchange a token to begin with), state inspectable
                by third parties.

                But truthfully, in a commercial setting, I mean this - if it doesn't
                get from A to B, just once, my ass is on the line. The purpose of
                the protocol is to fulfil a business need at a low cost. Most of the
                customers I work with are concerned about being locked-in to magic
                black boxes, so opening the protocol is important in that respect.

                Paul Prescod wrote up a great one pager on this a few years back on
                a model where the client and server exchange a URI token, and a lot
                of my understanding on what you can and can't do regarding reliable
                communications on the Internet came from Miles Sabin. I think you
                need a wee bit more than Paul outlined, but a hell of a lot less
                than any of the reliable-over-HTTP protocols I've seen.

                It's not baked yet, the main issues are what resource the URI token
                names (I think it's the exchange and not the message) and the
                PUT/DELETE debacle (well, I think it's a debacle :)

                Bill de hÓra
              • Mark Baker
                Erm, yah, that s the idea. Nice job. 8-) P.S. I tried to get SOAP 1.2 to support body-less envelopes for exactly the reason you really need them there. The
                Message 7 of 11 , Sep 14, 2003
                • 0 Attachment
                  Erm, yah, that's the idea. Nice job. 8-)

                  P.S. I tried to get SOAP 1.2 to support body-less envelopes for exactly
                  the reason you really need them there. The WG didn't like that idea.
                  But I'd just make the body empty in those case; no need to duplicate
                  what SOAPAction already makes clear.

                  On Fri, Sep 12, 2003 at 12:13:15PM -0400, sa3ruby wrote:
                  > Any thoughts on this:
                  >
                  > http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients
                • djpowell.geo
                  ... I implemented something recently that used Apache CGI to do it s own hand-rolled Basic auth. A trick that you can use to get Apache to supply a
                  Message 8 of 11 , Sep 15, 2003
                  • 0 Attachment
                    --- In rest-discuss@yahoogroups.com, "sa3ruby" <rubys@i...> wrote:
                    > Any thoughts on this:
                    >
                    > http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients
                    >
                    > ?
                    >
                    > - Sam Ruby


                    I implemented something recently that used Apache CGI to do it's own
                    hand-rolled Basic auth. A trick that you can use to get Apache to
                    supply a Authorization header to CGI scripts is to use these
                    directives in a .htaccess file:

                    RewriteEngine on
                    RewriteCond %{HTTP:authorization} (.*)
                    RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

                    Is there any other reason that you need to use a different name?
                    Remember that the "Authorization" header has special semantics in
                    section 14.8 - shared caches may not cache the replies to requests
                    that were sent with this header, unless arrangements are made to
                    specifically make them cacheable.

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