From: Mark Baker (distobj@acm.org)
Date: Tue Jan 02 2001 - 12:47:58 PST
> What the Soapy guys are trying to get across is that HTTP 1.1 doesn't provide
> any specific guidelines or standards at the API level of a typical
> application.
If that's true, then they're wrong. HTTP defines a very useful API.
They can argue that for their particular application, that those APIs
are insufficient. But they can't argue that HTTP doesn't give them
any application semantics to work with, because that's all it does; it's
an *APPLICATION* protocol ferchristsakes.
> SOAP does. One disconnect is that SOAP would typically use HTTP
> 1.1, which you are advocating, so it's unclear what you are trying to say in
> that regard. Another disconnect is that HTTP 1.1 is a raw transport with
> certain negotiation and commands but no standard determinant way to build
> specific APIs.
Wrong.
- HTTP is not a transport protocol
- HTTP already defines an API; GET/POST/PUT/HEAD/etc..
Let's try to explain this a different way;
HTTP says that all components on the Web must implement the RPC
interface
interface HttpWebComponent {
Stream GET (Headers h);
Stream POST (Headers h, Stream body);
etc..
}
and that the semantics on those methods must behave per HTTP 1.1
Whereas SOAP-RPC/XML-RPC users promote their own RPC interfaces such as;
interface StockQuote {
float getDelayedStockQuote( String ticker );
float getRealtimeStockQuote( String ticker );
}
interface WeatherReport {
String getWeather( String city );
}
The difference is an architectural principle sometimes referred to as
interface genericity. Yes, you lose some control this way, e.g.
interactions are relatively coarse grained. But you gain too. For
example, composition becomes a lot easier as later forms of binding can
occur between components, and components can be substituted for one
another. You also don't have to worry about standardizing on gazillions
of APIs; you just use one. Linda was another system that used this
principle; all spaces implemented the same interface (not unlike HTTP's,
in fact). Though it didn't get deployed widely (though perhaps more
widely than many systems of it's time), it was popular. More recently,
JavaSpaces did the same thing (it was based on Linda).
In case it isn't clear, the interfaces listed above are *not*
complementary; they are competitive. "HttpWebComponent" is a sufficient
expressively interface (when combined with the method semantics defined
in HTTP 1.1) to implement many *many* different types of applications.
> You do have both kinds of form submission standards (GET and
> POST) but no complex data type encoding or organization of results.
GET and POST are *not* "form submission standards". They are hypertext
transfer methods, of which form submission is one example of one markup
language, HTML. HTTP does not depend on HTML.
HTTP has its own encoding. As for body encodings, it punts that issue
except to describe the encoding of the body. "Organization of results"
is also punted to whatever organization the body wants, which could be
a MIME container containing multiple parts, or XML, or whatever. I
think
that's sufficient.
> On the other hand, SOAP doesn't seem to have a mechanism to reuse the MIME
> negotiation machinery at the API and sub API level. That's the only point of
> view where what you are saying makes sense to me.
Curious, because that doesn't make sense to me. 8-O
> > SOAP has (arguable) utility beyond its use for RPC, so I may keep it.
> > But I'd tell programmers to use the API that HTTP defines, and not
> > define their own.
>
> Unless all you have a API's with a few simple text arguments that return
> unformatted blobs of text/html, you need something more.
There's another reference to HTML. HTTP does not depend on HTML.
> You can return XML
> or whatever and interpret it any way you want or return a SOAP style response
> and have a standard way to find fields, data types, arrays, etc.
>
> As I see it, SOAP is just the barest standardized usage of XML but that's good
> enough to avoid a fair amount of wasted time reinventing that veneer each
> time.
IMHO, the attempt to proliferate RPC services on the Internet is the
biggest waste of time here, when the same value can be provided via
a much more useful, successful, suitable, and already massively deployed
means.
MB
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 12:46:37 PST