Re: Web RPCs Considered Harmful

(copy list trimmed to purely xml-dist-app, as requested)

On Fri, May 12, 2000 at 01:38:44PM -0500, Ken MacLeod wrote:
> I have written an article that describes major issues with Internet
> security and open standards when writing Web applications that rely on
> exposing their APIs over the Internet vs. Web applications that simply
> store data on Web servers.  This article is motivated by the growing
> popularity of SOAP and XML-RPC and the emphasis they place on RPCs.
> 
>   <http://monkeyfist.com/articles/514>
> 
> I want to be clear that SOAP is more (or less, depending on how you
> look at it :-) than just RPCs, it's the marketing focus and user
> interest in using SOAP for RPCs that matters.

Your article describes the difficulties well, and I share your concerns.

I've scribbled some reactions below. They're probably not 100% coherent,
but I wanted to get some comment in before we all set off for Amsterdam.

On the topic of security, I note with appreciation W3C's comment on the
SOAP submission at <http://www.w3.org/Submission/2000/05/Comment>:

"we think that security considerations should have a central place in
such a design, as it is always more difficult, if not impossible, to add
security afterwards."

The common response to security questions in the past has been "it's an
application level thing" -- but as you observe, most applications are
broken w.r.t. security. Getting a proper security model into the
protocol seems vital, because few will bother with decent security
otherwise.

On the topic of APIs fragmentation/lock-in, I also have concerns. RPC
makes it all too easy to push back the semantics into the application
layer and promote lock-in. 

I've thought about this, and I've come to the conclusion that sadly
that seems to be the way of the software world. If you consider a
web-rpc-enabled service to be a code library, then a pretty straight
parallel exists with the many code libraries that exist in both the open
and closed source worlds.  When consensus is reached, it's normally
because of a dominant player, although occasionally because of some
other impetus.

Although you point out that data transfer protocols have the opportunity
of avoiding lock-in, I'm not sure it's an API vs data transfer thing.
I can't see that it's any more difficult to obfuscate a data format than
an API.

If there's something to be gained by it, then we get openness, whether
by API or schema. I admit though I don't fully understand your
alternative proposal, and would benefit from a more detailed
explanation.

One thing that I've not worked out yet--and which would be instructive
to do in order to further understand the issues--is the flow of money in
the brave new world of web APIs. What products/services will be offered,
to whom, and at what cost? That will dictate as much as anything the
level of openness. If nobody can make money by being open then...

Thinking about this topic opens up more questions than it provides
answers. Where the Web is concerned, "broken" seems to win first thanks
to the network effect, then fixing has to be done in retrospect. We seem
to be at a crucial point here for XML protocols. If the W3C process
is cranked up and a year later out comes (hopefully) something that
addresses at least some of our concerns head-on, what will have happened
in the meantime?

Will not the marketing and general rush to embrace SOAP have caused it
to become the favored solution of many developers? 

I sometimes feel that we're trapped in this cycle where all we can do is
stand by, wring our hands, and comment on how broken things are. We can
even come up with clueful alternatives, but often to little impact.
Brokenness happens just the same, because adoption /is/ driven by
marketing concerns and the desire of users to have something cool.

If we really want to fix the problems before they happen, then the
clueful alternative needs to be the one that gets the marketing and
promotion. We may have just that chance in front of us.

Apologies to anyone bored by the stream of consciousness.

-- Edd

Received on Friday, 12 May 2000 16:54:39 UTC