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

Re: [rest-discuss] Re: First Tim Ewald, now the MS Data Access & Storage team....

Expand Messages
  • Bill de hOra
    ... I agree with Josh; what he s pointing at are the basis for deriving real world practical things like view source. I think REST is simple too, but where it
    Message 1 of 25 , May 4, 2007
      Mark Baker wrote:
      >
      >
      > On 5/3/07, Josh Sled <jsled@...
      > <mailto:jsled%40asynchronous.org>> wrote:
      > > On Thu, 2007-05-03 at 09:26 -0700, Mike Pittaro wrote:
      > > > With a REST architecture, it has been possible to build out that web
      > > > infrastructure over time, using whatever tools or frameworks are
      > > > appropriate for each site and it's content. Some sites use simple
      > > > tools, some use complex frameworks. Many started simple and grew over
      > > > time. But they all interoperate nicely, with a low cost of entry in
      > > > terms of whats required to get started. Tools and frameworks are good
      > > > things, the option to choose the appropriate tool for the job is even
      > > > better. That is a REST advantage.
      > >
      > > Is it? I think it's more a function of open (and libre-Free ones)
      > > specifications and protocols. Though REST does help to some degree.
      >
      > Sure. REST helps by providing oodles of simplicity.

      I agree with Josh; what he's pointing at are the basis for deriving real
      world practical things like view source. I think REST is simple too, but
      where it really helps is the way it organizes simplicity (no free lunch
      for architectural styles).

      cheers
      Bill
    • Steve Loughran
      ... Which is, IMO, the only way to run SOAP. two-way synchronous operations, not WS-A-addressed one-way calls that aren t even allowed to let you know you just
      Message 2 of 25 , May 6, 2007
        On 5/4/07, Bill de hOra <bill@...> wrote:
        > Nic James Ferrier wrote:
        > >
        > >
        > > "Steve Loughran" <steve.loughran.soapbuilders@...
        > > <mailto:steve.loughran.soapbuilders%40gmail.com>> writes:
        > >
        > > > p.s, say what you like about SOAP, but in REST, the enemy of GET is
        > > > the proxy server that thinks it knows better. The one that returns
        > > > 200+text/html when the far end 401s on you. The one that caches stuff
        > > > for weeks, even when the TTL is seconds. The one that caches an
        > > > incomplete download and serves up to other callers.
        > >
        > > Errmmmm... isn't this true of SOAP as well?
        > >
        > > A proxy that was that badly implemented (and I agree that some proxies
        > > ARE that badly implemented) would fek up a SOAP call as well.
        >
        > Not in the good old days when all SOAP calls ran over POST.
        >

        Which is, IMO, the only way to run SOAP. two-way synchronous
        operations, not WS-A-addressed one-way calls that aren't even allowed
        to let you know you just tried to post ill-formed XML.

        There is a least one GET-related bug in classic Axis1.x. The
        happyaxis.jsp page is designed to perform passive system diagnostics.
        Although originally meant to for loadbalancing routers to use, it has
        become the normal way to check that Axis is installed. Indeed, a
        search for "Axis Happiness Page" will show you the internals of many
        axis installations out there.

        Its a JSP page, and is designed to be (a) entirely standalone and (b)
        easily extensible by users. So there are variations for things like
        apache muse and other SOAP-based services.

        But, the little JSP page doesnt set the cache expiry info. So while it
        works well for dev systems on the local net, if you go live with
        something beyond the firewall, or if you are trying to do interop
        tests against remote systems, checking for happyaxis only shows you if
        the proxy server has, at some point in the past, been publishing a
        status page.

        now we have a proxy server that caches things for a couple of days,
        and if the server at the far end is not there, it serves up the old
        stuff without any warning that the content is really, really out of
        date. Which makes checking the base happyaxis.jsp page useless, unless
        you tack on some random query string at the end, which is what I ended
        up doing:
        http://smartfrog.svn.sourceforge.net/viewvc/smartfrog/trunk/core/components/deployapi/build.xml?view=markup

        And do you know who it was that left the cache-expiry headers out the
        JSP page? It was me. So now I am suffering because I forgot to add it
        four years ago, and the JSP page and derivatives are out in the wild
        and I have to test against them.

        I dont think the ?WSDL pages set cache expiry information either. Oops.

        Summary: even if SOAP over POST itself doesnt have proxy cache
        problems, the other bits of the stack can do it. And, because the
        people writing SOAP stacks tend to live in the SOAP world rather than
        the depths of HTTP, they tend to forget about some of the details of
        layers underneath, like the effect of proxies.

        -steve
      • Bill de hOra
        ... Not even remote. I ve been bitten by the same kind of problem in production: - when someone set an admin page for Servlet timer to stop/start using GET
        Message 3 of 25 , May 6, 2007
          Steve Loughran wrote:

          > Its a JSP page, and is designed to be (a) entirely standalone and (b)
          > easily extensible by users. So there are variations for things like
          > apache muse and other SOAP-based services.
          >
          > But, the little JSP page doesnt set the cache expiry info. So while it
          > works well for dev systems on the local net, if you go live with
          > something beyond the firewall, or if you are trying to do interop
          > tests against remote systems, checking for happyaxis only shows you if
          > the proxy server has, at some point in the past, been publishing a
          > status page.

          Not even remote. I've been bitten by the same kind of problem in production:

          - when someone set an admin page for Servlet timer to stop/start using
          GET (once it didn't start at all resulting an a very awkward meeting;
          another time it didn't stop, so two timers ended up running after a
          'restart' screwing up the internal app state).

          - when someone set a batch job control using an .asp page to be
          started using GET (the browser returned from cache, never got to the
          origin server).

          - when the Tomcat team thinks you should manage webapp lifecycles
          using links. Tomcat is the Servlets *RI* for heaven's sake.

          I was listening to drunkandretired 93 a few nights ago. It seems the
          Rails crowd still think GWA is evil broken software, and the Rails use
          of GET links is fine (this months after the "world of resources" shift).
          I said last week how could people not understand REST until now, that I
          thought it was willful disregard by the technical community due to
          commercial 'on message' pressures; and now those are fading, people can
          out safely. But I wonder.

          cheers
          Bill
        Your message has been successfully submitted and would be delivered to recipients shortly.