So, from my last installment, I left off with this: My daily situation with regards to integrating the web-based services of various parties boils down to what I can explain in 30 minutes to a developer of unknown competence to whom I'm barely a priority. So far, I've been able to apply XmlRpc as a solution to this problem with a great degree of success.

About this, endulging me although I'm sure issues like mine have been hashed out a million times already on various mailing lists, Paul Prescod writes:

There's nothing wrong with the way you've used XML-RPC and I've used it that way myself. I only write to ensure that you (and anyone reading) understands the costs and benefits of this approach. You've given up on many of the feature of the underlying XML and HTTP technologies. If you don't need the features, then amen, let her rip. But people building more substantial apps do need them.

Yes. So, I know that my chosen solution has its blemishes and land mines awaiting my step. But, none of them have bitten me yet, nor do I expect them to for some time. On the contrary, for every practical application of XmlRpc we've deployed, we've had happy clients. While working in this industry, the 80/20 rule has been beaten into me - so if a solution that's 20% complete solves 80% of our problems, it's time to move onto the next problem.

This, however, is a dangerous thing to become complacent about - there're still 20% worth of problems out there for which this solution falls down. And each one will become a work-till-3-am nightmare when they hit. And besides, I'm a perfectionist and a purist at heart, so the dirtiness of this solution will never fail to irk me. It may be simple, but simple is not necessarily elegant. So what about the rest of Paul's points?

The first axis of flexibility you've given up is in character set. XML-RPC disallows Unicode character strings.

On one hand, my impulse is to respond to this by invoking YAGNI - since our use of XmlRpc involves messages between machines, I don't care about localizing those. I'll just keep to language neutral data in there. But, I'm naive. With a bit of pondering, I can identify at least one area where user-supplied input needs to be traded - shared registration and login for global promotions. And if I can identify one, there's bound to be more. I don't have as much experience with Unicode and handling languages other than English as I'd like, so I can't trust my assumptions here.

XML-RPC is brutally non-extensible. ... Dave Winer has been actively hostile to every effort to evolve XML-RPC.

In this case, I'd say this is a good thing, for XmlRpc in particular. It does what it does, no more and no less, and this will never change. I will never need to bring up versions of the spec in my 1/2 hour conversation with the junior engineer. And though I don't want to second guess Dave Winer, I assume this is the goal in his insistence on XmlRpc being ever frozen. The alternative at which he points, if memory serves, is SOAP.

The third aspect: XML itself. What will happen when and if your industry, whatever it is, canonizes a schema for what you do, like the hundreds of existing ones. ... Maybe your industry isn't organized enough to define a schema for whatever it is you do.

Bingo. Our industry is neither mature nor organized enough to conceive of any sort of schema. Our products and the concepts involved in our work are in constant change, not to mention the conditions of the market and what will continue to work.

Another way of attacking your interoperability problem would be to start from that point of view, defining the XML and then working back to the REST system. That's a much more natural way to define a REST-based web service and is arguably a better way to define web services in general. I would be curious whether you tried this.

Nope, haven't tried this. This is where I start calling things "ivory tower". To me, it makes elegant sense.

You say you tried "REST-ish URL schemes" but that isn't the same as trying REST. In particular, you don't say much about what your XML strategy was.

Calling our early interop schemes "REST-ish" may have been too strong an association with REST. No XML strategy. More like: "Make a GET to this URL with these query parameters, documented here. You'll get a simple text response back, documented here." This was always balked at, though I thought it was the simplest thing in the world. I might have some thoughts on the failure of this, if I think about it some more.

I don't know your suppliers, but in the vast majority of situations I have been exposed to, they "get it" if you tell them: "here are some XML example documents. POST things like that to me when you want me to do something and GET them from me when you want to get information from me."

Whenever XML is brought up, fear rises and eyes glaze. We're the "supplier" in most situations, and it's rare that our clients are tech-centered companies. They have a web site, and maybe a team maintaining it if we're lucky.

You depicted the situation as SOAP on one side (grungy), REST on the other (ivory tower) and XML-RPC in the middle. REST is basically the same old CGI-ish stuff we've been doing for a decade so I don't see how it is very ivory towerish.

Well, I'm mixing audiences here. SOAP, to me and my lack of time with it, seems grungy and in flux. To my clients, REST seems out there, especially if I ever try to explain to them what the letters stand for. :)

"What's a siggy?"

"You mean a C-G-I?"

In explaining XmlRpc, I usually say something long the lines of "your people's boxes talk to my people's boxes," then point them at the website that says largely the same thing. Of course, this begs the question of my effort and competence in explaining REST to others, which I feel is lacking thus far. Because, well, REST is also their boxes talking to my boxes. And, I haven't found a website at which to point both techie and non-techie audiences to "get it".

...perhaps REST doesn't apply to you. Yet. ... You say that REST doesn't "feel finished" to you. Nor to me. Our industry is in the middle of a huge migration to extensible formats like RSS which builds on RDF which builds on XML.

I don't think REST quite applies to us yet. I'd like it to. Maybe once we, as a company, have formed much stronger partnerships I can get past the 30 minute barrier and get to some real discussions and establish things like XML schema.

When people are comfortable with extensible, hyperlinked formats, REST will seem like a no-brainer.

The more I read and think about REST, the more I agree with this. It's just that I find it very hard to sell the idea yet. Again, this may be the nature of the beast for whom I work, and it may be my lack of ability to describe this simply.

But for now, it seems that the ability to throw a random unknown web developer an API and a URL with less than 30 minutes' accompanying discussion, and get results, seems to work for us.

shortname=oooccd