posted by ![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
sbisson at 07:13pm on 29/09/2002
sbisson at 07:13pm on 29/09/2002The XML column I'm in the middle of writing is the first of two on working with the Amazon web services API.
Looking at it in more detail as I research and write the piece I've found the API an extremely interesting piece of work. The query URI structures used in the XML/HTTP version of the API are very interesting, as it's clear that they've been designed to be both relatively easy to design and use and to map relatively easily to the backend SQL queries that Amazon will be using on its databases. A query URI for a search that's exploring just one area of the Amazon site looks like this:
http://xml.amazon.com/onca/xml?v=1.0&t=webservices-20&dev-t=[Developer's ID goes here]&BrowseNodeSearch=[browse node goes here]&mode=[product line goes here]&type=[lite or heavy] &page=[page # goes here]&f=xml
You can see just how the resulting code on the Amazon side will operate. It will first authenticate using the Developer's ID, place restrictions on the search scope using the browse node information, and finally chooses the type of document returned (along with the page number in the query response). This type of request will allow you to see the most popular items in a product class - so you could use it to deliver a regularly updated list of top selling books or CDs for a web site.
It's an interesting piece of work, and something I'm going to need to keep in mind as a design pattern for future KM work.
Looking at it in more detail as I research and write the piece I've found the API an extremely interesting piece of work. The query URI structures used in the XML/HTTP version of the API are very interesting, as it's clear that they've been designed to be both relatively easy to design and use and to map relatively easily to the backend SQL queries that Amazon will be using on its databases. A query URI for a search that's exploring just one area of the Amazon site looks like this:
http://xml.amazon.com/onca/xml?v=1.0&t=webservices-20&dev-t=[Developer's ID goes here]&BrowseNodeSearch=[browse node goes here]&mode=[product line goes here]&type=[lite or heavy] &page=[page # goes here]&f=xml
You can see just how the resulting code on the Amazon side will operate. It will first authenticate using the Developer's ID, place restrictions on the search scope using the browse node information, and finally chooses the type of document returned (along with the page number in the query response). This type of request will allow you to see the most popular items in a product class - so you could use it to deliver a regularly updated list of top selling books or CDs for a web site.
It's an interesting piece of work, and something I'm going to need to keep in mind as a design pattern for future KM work.
geeky
(no subject)
f=xml. That I would take to be a promise that they won't go changing either the query terms or the XML schema (though they could easily and compatibly add to either of them).This stability is what makes it an API, not so much the XML; they could return comma-delimited text or even HTML; what counts is that it's documented and stable.
SOAP is a red herring: if you change your SOAP schema every two weeks you don't have a web service API that anyone can use. Keep your search terms and results stable and you indeed have a web service people can rely on.
I've been doing some server-side stuff recently that relies heavily on consistently-formatted URL's and returns plain text that's easy to parse in Perl. Works great and it's trivial to debug.
(no subject)