[
Lists Home |
Date Index |
Thread Index
]
Francis Norton wrote:
>
> Paul Prescod wrote:
>
> <snip/>
>
> >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.
In what sense is it NOT a web service? The routes probably live in a
database and are dynamically generated. The data is on the Web. You're
talking between a software component on the client side (as opposed to a
browser) and one on the server side. Yes, it "looks like" just a web
page but that's the point: Web services do not have to be architected
using a totally different methodology than web pages.
>...
> Um, perhaps I should have chosen a more complex example, eg the Google
> interface,
Well I've already shown how you can use a query for the Google interface
in my xml.com article!
> ... or adding (as the real system does) departure or arrival
> dates and times to the query parameters.
You could do all of that through hypertext too. But if you really want a
query interface I don't see the problem.
http://www.flyawa.com/cgi/air?stamp=NEWCOOKY*itn%2Ford%3DNEWREC%2Citn%2Fair%2Famericawest&airline=america+west&rt_ow=Round+trip&depart=PVR&dest.0=PHX&mon_abbr.0=May&date.0=2&hour_ampm.0=8+am&mon_abbr.1=May&date.1=2&hour_ampm.1=8+am&air_class=coach+%28lowest+avail.%29&adults=1&children=0&persons=1&ecert_num=&submit1.x=88&submit1.y=3
> ... 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.
Who said I was using a static back-end? Maybe the information lives in a
database and is updated once per second.
> > 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.
I'll point out again that just because you can use hypertext and URIs
without using static content!
> > 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.
Diversity of formats is a fact of life. It is unavoidable in any
architecture. The question is whether the architecture handles it
gracefully or not.
> > 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.
Query parameters are NOT representations of resource. Query parameters
are part of the address for resources. The representation is the thing
that you get when you do a GET or the thing that you PUT or POST.
Paul Prescod
|
