[
Lists Home |
Date Index |
Thread Index
]
On Wednesday, September 25, 2002, at 06:59 PM, Rob Griffin wrote:
> The first one accesses my mobile (cell) phone provider's web site
> using HTTP
> and HTTPS to use a facility they offer where you can send an SMS from
> a web browser.
> This involved grovelling through HTML to find the form tags to
> determine what
> fields I needed to send and sniffing the data sent on the connection
> to see
> what cookies were being used. All in all a very 'hacky' way of
> developing an
> application, and the result is pretty fragile. Any errors that are
> returned are
> embedded somewhere in the HTML. Any changes to the forms break the
> application.
> Development time was several hours.
In my previous job at 2Roam (R.I.P.), I worked on several HTML scraper
to WML/HDML applications, so I sympathize with you and agree that those
applications are incredibly fragile (especially when the customer
doesn't let their HTML production group know that the HTML has to be
stable for us to parse it.)
However, I don't think that the example is a canonical example of a
REST application. If your SMS provider's interface had the capablity to
return status and error messages in XML, then your integration would
had been easier (you don't have to parse a non-semantic document, i.e.
the status was in the h2 in fourth nested nested table's third row,
second td off of the body, except when they send an ad for their new
handset), and stable (the message structure doesn't always change when
they switch ad servers).
If the customer publishes neither a REST or nor SOAP interface, you're
in fix in either case.
> So here's the question. What is the alternative to Web Services? REST
> advocates
> say REST is best, but there is no toolkit for creating or using REST
> based
> services that I know of. Accessing current web sites that return HTML
> is
> not acceptable or easy to do. Things like cookie management and login
> mechanisms
> should be transparent to the caller of the service.
I agree, that in order for REST to work, you need the service to
provide either a simple HTML document that you can parse for results,
an XML format for message, or even return plain text. However, if the
provider publishes an API (say such as the one Amazon created, or
Moveable Type's trackback API), then you don't need a toolkit.
Sorry if I'm rehashing old ground or opening old wounds, but having
been in Rob's situation, I did want to respond that REST is an
alternative.
Cheers.
----
Bill Humphries <bill@whump.com>
http://www.whump.com/moreLikeThis/
|
