Re: [rest-discuss] Re: First Tim Ewald, now the MS Data Access & Storage team....
- On 4-May-07, at 2:19 PM, A. Pagaltzis wrote:
> * Toby Thain <toby@...> [2007-05-04 17:30]:Yeah, I didn't get Josh's point at first. Since corrected. :-)
> > On 4-May-07, at 11:59 AM, Josh Sled wrote:
> > > ... it also "degrades" simply: you really can just say:
> > >
> > > $ echo -ne "GET /foo HTTP/1.1\r\nHost: host\r\n\r\n" | nc host 80
> > Pedantically speaking, so will:
> > $ curl http://host/foo
> Yeah, but curl is explicitly an HTTP client, whereas nc doesn’t
> implement anything beyond TCP.
> However, HTTP sticks to the essentials so well that you need
> nothing more than a TCP implementation to get useful work done. ...
- Mark Baker wrote:
>I agree with Josh; what he's pointing at are the basis for deriving real
> 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.
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).
- On 5/4/07, Bill de hOra <bill@...> wrote:
> Nic James Ferrier wrote:Which is, IMO, the only way to run SOAP. two-way synchronous
> > "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.
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
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
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 Loughran wrote:
> Its a JSP page, and is designed to be (a) entirely standalone and (b)Not even remote. I've been bitten by the same kind of problem in production:
> 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.
- 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
- 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.