RE: Issue 5; GET vs GetLastTradePrice

David,

I definitely agree with you.

In my opinion for some request-response operations you can use either HTTP
GET or HTTP POST, and for some you can only use HTTP POST. I don't see a
significant difference to justify using HTTP GET for some and HTTP POST for
others. This ad-hoc optimization does not buy much to justify the
complexity.

My best practice: if you build an operation that could support both HTTP GET
and HTTP POST, you should use HTTP POST since it supports the generic
interface. And this actually conforms to the principles of REST which
recommend using the more generic method ;-)

However, there is a particular use case where you ware performing an input
operation. When you retrieve the last value of a stock quote - a very
specific example, not a generality of what Web services do - the service is
actually doing an output operation. There is no input message to speak of.

Let's say a stock value changes five times over the course of a minute, and
you retrieve the value every minute. You retrieve only one in five messages.
Which is acceptable since you don't care about historical value. Essentially
what you are doing is saying "give me the last message sent on this topic".
In my opinion HTTP GET should be used to retrieving output messages with
output only (or output-input) operations.

Think of hypermedia applications as a form of publish/subscribe. The URI of
a document is a topic of interest. The content of a URI is the last message
posted to that topic. The subscriber is interested in retrieving the last
message posted. The subscriber does not provide any input that causes the
output message to be created. So the subscriber would use HTTP GET.

(The implementation may use lazy generation to generate the output message
on demand using data from the URI, but lazy generation does not "create" a
new message, it simply generates it on demand, so conceptually it still
holds true that the message exists prior to the HTTP GET operation)

If we look at HTTP servers as a persistent publish/subscribe medimum, then
indeed HTTP GET would be a way to retrieve a message from the medium, and
HTTP PUT could be a way to publish a message to that medimum.

(You won't see the HTTP PUT in the WSDL definition since the publisher does
not have to inform the subscriber how it publishes the message, only how to
receive it, and the publisher does not have to use HTTP PUT per se, it could
response to HTTP GET request dynamically, update a file on the file system,
update a record in the database, do an HTTP POST into storage, etc).

Of course, having read this, I just realized I am touching on multiple
points here, not all of which are concensus at this point:

1. Publish/subscribe in Web services and using HTTP GET for output-only
operations
2. Defining hypermedia applications (which as Roy points out are quite
common) as a form of pub/sub
3. Illustrating that if WS supported persistent pub/sub and used HTTP GET
for output-only it would be RESTful
4. Illustrating that WS could follow REST principles even when it talks
about non-RESTful applications (if it elected to always use HTTP POST for
input-output operations)

arkin


> Mike,
>
> Interesting POV.  I offer my limited analysis.  The web is optimized for
> ad-hoc retrieval of resources, specifically around using GET.  It's the
> default method given only a URI.  Therefore people can easily
> post (:-) them
> on billboards, send via email etc.
>
> In the web context, it makes huge sense to be able to give around
> URLs.  And
> the default method of GET is completely required for this success.  I want
> to re-state my position, which is that the web was successful
> because of the
> combination of URIs and the default use of GET.  And when people
> use POST on
> web sites, they typically use it interchangeably with GET.  I've
> proven this
> point in the past.  Therefore the web architecture may be designed around
> REST, but in actually it's almost 100% deployed in a simple one method
> invoke style, and this is the case that the web is brilliantly optimized
> for.  Almost nobody deploys GET/PUT/POST/DELETE methods on the same URI.
> 99.9% of sites treat POST/GET as interchangeable.
>
> The question from a Web services perspective, is does this same
> optimization
> make sense?  Do we have programs that already have prebuilt "method"s, or
> even a default method, and we simply have to punch in new addresses?  I
> don't think so.
>
> IMO, ad-hoc retrieval of representations doesn't make as much sense in a
> machine to machine world, as compared to a hypermedia world.
>
> The architectural middle ground that I believe we are moving towards is a
> model that is optimized for program creation - hence the
> necessity of wsdl -
> and allowing for ad-hoc invocation - hence the support for GET.  The
> optimization is different, but the features are supported.  I also believe
> that the default method for web services will be the POST method.
>
> One of the areas that we (Web services) still have work to do is
> in figuring
> out how to deploy Web services across trust boundaries.  The use of tcp
> ports and port firewalls make sense when it was really hard to create and
> deploy applications.  Think of how long it took to get the protocols over
> the various internet ports figured out.  But now we want to scale this for
> gajillions of applications while wanting the firewall admin to
> actually do a
> reasonable job at setting up the right policy.
>
> To me, XML is the thing that breaks the previous model of dealing with
> internet level application deployment.  10 years ago, it was
> fairly hard to
> create document formats and protocols.  XML made it orders of magnitude
> easier to create formats.  SOAP makes it an order of magnitude easier to
> create .... XML based protocols.  People that focus on the use of URIs and
> GET as the focus on app development, IMO tend to ignore the whole
> centralized registry of ports and description of the HTTP protocol as well
> as the commensurate programming that the HTTP developers had to do.
>
> If there is any argument that would convince me that GET is better than
> GetLastTradePrice, it would be the firewall argument.  But having spent a
> few times discussing the realities of deployment of the various
> options with
> MarkB, I remain unconvinced that the firewall admin has any
> greater insight
> or control into application of security policy under one or the other
> choice.
>
> Which makes me believe that we still have a hole in the web services
> architecture on what needs to be in soap messages and wsdl definitions in
> order to allow a firewall admin to do their job better.
> SOAPAction was one
> attempt at this.  WS-Routing Action was another.  There are various other
> approaches.  But I don't think we've taken a very systematic and thorough
> approach at looking at the use case of a web service being developed and
> deployed by developers and security people.
>
> Cheers,
> Dave
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Champion, Mike
> > Sent: Thursday, January 02, 2003 8:41 AM
> > To: www-ws-arch@w3.org
> > Subject: RE: Issue 5; GET vs GetLastTradePrice
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Walden Mathews [mailto:waldenm@optonline.net]
> > > Sent: Thursday, January 02, 2003 10:37 AM
> > > To: Newcomer, Eric
> > > Cc: www-ws-arch@w3.org
> > > Subject: Re: Issue 5; GET vs GetLastTradePrice
> > >
> > > I'd like to get clearer on what that middle ground is.  Last
> > > summer I got involved in a project that
> > > had already decided to use XML in a "document" mode as
> > > opposed to a "RPC" mode, but the
> > > distinction was only skin deep, at least according to my
> > > analysis.
> >
> > I sometimes suspect that too.  As someone said in one of these recent
> > threads, it would be hard to distinguish an instance of one
> > from the other
> > using a protocol analyzer. The distinctions do seem more at the design
> > pattern level-- do you CONCEIVE of the message as a method
> > invocation with
> > arguments that gets directly mapped onto a procedure call of
> > some sort, or
> > do you conceive of it as a business document to be acted on by some
> > intermediate software that interprets the data and indirectly
> > invokes the
> > back-end software.
> >
> > I'm  seeing this more and more as an engineering question of
> > finding the
> > optimal degree of coupling in a particular web application
> > than as some huge
> > meta-question of competing paradigms. The tighter coupling of
> > direct mapping
> > of method invocations (synchronous or asynchronous) on one
> > system to another
> > via SOAP messages makes sense in stable, well-managed systems where
> > performance considerations are paramount; the looser coupling
> > of business
> > document exchange makes sense in more dynamic, hapharzardly
> > managed systems
> > where ease of discovery by new "customers" is more important than
> > performance for existing customers.
> >
> >
> >
> >
> >
> >
> >
> >
>

Received on Thursday, 2 January 2003 15:01:55 UTC