Lists Home |
Date Index |
Paul Prescod wrote:
>You've never done a query and you've never had to
>send complex XML.
This is an argument for not doing Web Services at all. I have to say my
real interest is in doing Web Services in as REST-y a way as possible.
>When you do it this way:
> 1. the client's access to the data is not mediated by any API or
>messaging interface. This is very much in the XML spirit of "give me the
>data and I (the client) will figure out what to do with it.
OK, this makes sense.
> 2. you cannot generate a "bad query" by trying to get from London,
>Ontario to North Berwick, Scotland (nor North Berwick Maine to London,
>England!). If there is no link for that route then you can't get there.
Um, perhaps I should have chosen a more complex example, eg the Google
interface, or adding (as the real system does) departure or arrival
dates and times to the query parameters. I am interested in the boundary
conditions for where you should use static and dynamically generated web
pages, but my real interest is in what happens once you've decided to
implement a dynamic back-end.
> 3. the client can discover routes, rather than merely generate them and
>test whether they exist or not. For instance it could say: "hmmm. I
>notice a route from London to Glasgow and Glasgow to North Berwick.
>Maybe this is also interesting to my user."
This scales better for transaction volume, but dynamically-generated
content sales better for complexity - eg how much is the ticket going to
cost, all the complex stuff I mentioved above.
> 4. the standardization of the "routes" format and the "times" format
>can actually be fairly disconnected. For instance we might use the same
>"times" format for airlines and trains but the "routes" format might be
>different. Or else we could use XML extensibility features to share both
>but have different details on both.
I'm interested in Web Services, allowing program to talk unto program
over the net while adding as much Web-type value as possible. So
diversity of formats is not an incentive for me, except in so far as it
enables better formats to emerge as de-facto standards.
> 5. the server can easily serve these as either dynamic OR static
>documents. The performance advantages to the latter should be obvious.
Yes, this is a good argument for having a GET interface to Web Services,
but I'm still not certain whether it is possible to model query
parameters, for those cases where we admit they are needed, as
representations of resources.
Thanks - hope your teeth aren't getting ground down to their stumps yet!