Answer me this; is it the objective of the Web services architecture
to permit a document (e.g. a purchase order) to be submitted to any service
for processing?
If so, then how is this different than having every service implement
a common “process this document” (aka POST) operation? That’s what uniform
means.
Savas says
that iTunes is doing a proprietary version of Web services. I don’t think so. He writes;
If, however, they wanted to describe the structure of that information, how would they do it? Theyd probably use XML Schema.
Yep, agreed there. I think RDF would be a better solution, but given they’re
using plain old XML, XML Schema would be the way to go.
And if they wanted to describe the message exchange patterns, the contract for the interactions with the store (e.g., “when the XML document with the order information for a song comes, the response will be the XML document with the song”)?
Hold on. Why would they ever do that? Why would they want to artificially
restrict the type of documents returned from an interaction? That would mean
that if they wanted to insert a step between order submission and and song download,
that they’d have to change the interface and its description? No thanks. I would
prefer that the client determine what to do based on the type of the document that
actually arrives. Let’s keep the perpetually-static stuff in the protocol, and
let everything else happen dynamically.
And if they wanted their service to be integrated with other applications without having to read Apple specifications on how to include the information in HTTP requests and how to read HTTP responses?
I don’t follow. One need only look at the HTTP spec to determine how that’s done.
SOAP buys you nothing in that case, AFAICT. It buys you other things (better
extensibility, richer intermediary model, etc..), but none of those seem relevant
to ITMS at present.