Mark Baker wrote:
>
> > There are still a lot of disconnects here..
>
> I don't think there's lots. I think the main disconnect is simply that
> you believe it's best for application developers to define their own
> network interfaces, and I believe it's best for that to be generic.
>
> > It's about enabling cross-platform over-the-Internet procedure calls passing
> > data structures in an intermediate format that are translated to a
> > programming language's internal data structures invisibly to the programmer.
>
> Rephrasing my comment above, you believe that your stated big picture goal
> can be achieved by encouraging application developers to define their own
> APIs for their software components. I however, believe it's best if they
> can agree on a common API. Moreover, I believe that HTTP 1.1 defines just
> such an API.
Great, I get to play translator again:
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. 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. You do have both kinds of form submission standards (GET and
POST) but no complex data type encoding or organization of results.
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.
> > It's so simple I can't understand what's so controversial about it.
>
> Tell me about it! 8-)
>
> > Put it another way: What's your prescription? Withdraw XML-RPC and SOAP and
> > tell the programmers to ask Mark how to do interapplication communication?
> > If so, what would you tell them to do?
>
> 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. 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.
> Happy New Year all,
>
> MB
sdw
-- sdw@lig.net sdw@insta.com swilliams@Jabber.com Stephen D. Williams Insta, Inc./Jabber.Com, Inc./CCI http://sdw.st 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Dec2000
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:17:44 PDT