[
Lists Home |
Date Index |
Thread Index
]
Matthew Gertner wrote:
>
> Thanks Simon, there's a lot of really interesting stuff there. What I found
> most interesting was the article by Frank Moss linked from the web log. I
> can't get too excited by the REST vs. SOAP debate because there is such an
> overwhelming precedent for ugly technical "standards" push by large
> companies to win out over much cleaner and more sensible alternatives.
Matthew, if it was a case of cleanliness versus ugliness I would
absolutely agree with you. That's why I haven't proposed a "clean"
alternative to the SOAP encoding or other uglinesses. The issue is that
one model allows certain types of declarative, distributed XML-based
applications to be built and the other makes them so costly as to be
infeasible. When one solution meets requirements that the other does
not, it cannot and will not go away -- even if the mainstream chooses to
use the less powerful solution. That's why IP was not and could not be
killed by NetBEUI or IPX, no matter how many corporate installations of
the latter there were. When people realized that their needs were not
being met they were forced to switch, despite the cost.
>....
> Anyway, Moss's article points to a much more fundamental point: why bother
> with all the web services stuff in the first place? If it's just a way to
> replace one kind of API with another, then the effect is going to be
> incremental at best.
I agree. That's why I discourage thinking of web services as APIs and
encourage thinking of them as writable information resources.
>.... Certainly not enough to justify the amount of attention
> that web services are getting. Having XML interfaces to web pages is a vital
> first step, but in itself it doesn't represent any quantum leap forward.
I disagree heartily. It's a MASSIVE leap forward. Making the data
available in an easy-to-process form is a really, really important first
step. Nevertheless I agree that it is a first step.
> I constantly find myself wanting to build little custom applications that
> consume web data and do something useful with it. For example, consider the
> process by which I decide what movies to see. First I go to the local film
> listings (www.dokina.cz) and check out what's playing in my favorite Prague
> cinema. Since the names are in Czech, I then click on a movie to see the
> description (and translation of the name into English, which is the only
> part I care about). Then I go to www.imdb.com and check out the user rating
> (from 1 to 10). If it's an 8 or more, the movie's a winner, otherwise I
> might want to investigate more. In this case, I click on the external views
> and check out Roger Ebert's star rating (I don't read the article so as not
> to spoil the suspense). Since Ebert has his own bizarre agenda, I also check
> the Tomato meter on Rotten Tomatoes. I then go back and repeat the whole
> process for the next movie.
>
> What a pain. Wouldn't it be nice if I could quickly assemble an app that
> consolidates all this information on one page for me?
Even if the technologies available were perfect, I don't think that the
different web sites have much incentive to help you build this
application. Who will decide what advertisments you see and how will
they ensure you aren't filtering them out. Maybe if you were a paid
subscriber to each information resource but that gets quite expensive
and complicated too...plus they need to worry that you are proxying
their information to non-subscribers in real-time. Lots of messy
business issues.
Nevertheless, if all of the information were in XML, and you are
programmer then of course you can probably build this application in a
half day or so. That's not as good as point and click but better than
today's situation!
>...
> I suppose someone is going to point out that I can do all this in Python or
> whatever if the appropriate XML interfaces are available. But the success of
> the Web is based on the fact that the barriers to entry are so low... even
> people who barely figured out how to turn on their computer are soon happily
> clicking through the hyperlinks. To me the culmination of web services will
> be when I can put together a quick app like this by pointing and clicking at
> the appropriate areas of a set of web pages (implying that the web pages of
> this type are generated from the underlying XML... a big and important part
> of the web services idea IMO). This idea applies equally well to B2C and B2B
> applications with web interfaces.
There are two parts to your application, in my mind. The first is the
aggregation of information. The second is the application of business
rules. The aggregation of information can be done today. That's what
portals do. Perhaps the purest expression of your vision is Meerkat, in
that it aggregates such a large number of information resources. I think
that HTTP+URIs+XML is indisputably the way to do that part.
The second part is the business rule application. This is more tricky
and I see no reason to believe that web services (whether REST, or SOAP
or whatever) will make this really easy. Vendors tell you differently
but I do not believe them. We've never gotten to the point where LOCAL
app building can be done by "people who barely figured out how to turn
on their computer". Why would it ever be easier to build DISTRIBUTED
apps? IMO, the best we can hope for is Hypercard or VB or Python or
whatever you think the epitome of ease of use is. And that's not easy
enough, according to your criterion.
>...
> I feel like I must be stating the obvious here, but maybe not... apparently
> people seem to think that web services are about some sort of new RPC whose
> only advantage is that it has a lot of marketing momentum behind it.
True, that's what a lot of people think. I see it as a shared
application integration platform, and see RPC as a poor application
integration technique.
Paul Prescod
|
