I can say that in my experience I have explained REST to a variety people who’ve never worked with IDL or WSDL, and they don’t seem to have any problem understanding it. I’ve explained it to others who have worked with IDL and WSDL, and while they don’t always get it right away, they do get it if they’re able to put aside their IDL/WSDL assumptions. The ones who can’t see past IDL or WSDL, of course, never get it, but I think one can safely argue that they don’t really try to.

Also keep in mind that “difficulty” is a concept that ranges beyond the initial work a developer has to do to write the system. It might be easier in the short term for someone to write an interface in a definition language and push a button to generate code to create a system, but the resulting generated code is brittle, hard to version, hard to scale, and hard to update across the system in a piecemeal fashion.

Thanks for taking the time to write back. I appreciate it. I whole-heartedly agree with each of your points:

WSDL creates tight coupling, and this is bad.

Code generation is brittle, can create unnecessary data definition dependencies, and inhibits extensibility. All bad.

I know you’ve touched upon how REST is intrinsically more scalable than WS-*. I agree.

I believe my key failing here is that I failed to adequately explain the problem I am trying to solve.

I make embedded systems. More specifically, I make a device that can remotely reboot or power control a server in the same fashion as pressing the reset or power switch on the front of the server’s chassis. The device, named the WebReboot, can also measure the temperature inside a server, and tell you if the server is powered on or off. It’s core application is the remote recovery of crashed servers.

The interface for the WebReboot is tightly coupled to the hardware. We use a relay to control the power switch or reset switch of a server. We use a thermistor to measure temperature. The hardware has remained relatively unchanged for quite a long time, largely because it is simple, reliable, and cost-effective. Since the hardware has remained relatively unchanged, the interface has remained relatively unchanged. The extent of changes are limited to adding complimentary functionality that does not affect existing functionality (for instance, if I added a humidity sensor).

Scalability is largely not a concern for this application. In practice, it is not necessary to have many folks or systems trying to reboot a crashed server or retrieve a server’s temperature simultaneously.

Since my functionality is limited to what’s implemented in relatively simple physical hardware (e.g., sensors and relays), I’ve found limited application for complicated data structures and dependencies in controlling this hardware. I’ve also found limited application for extensibility. I’ve come up with many hypothetical ways for their application, but I haven’t found a need to use them. For these reasons, I haven’t in practice found the generated code for Java, Python, PHP or .NET to be brittle.

The biggest challenge I’ve had as a small company (< 10 people) competing in a large market (IT hardware) is competing with organizations that have significantly more resources than I do (Servprise was bootstrapped, and several of my competitors are public companies). One thing I noticed was that my competitors were largely offering stove-pipe solutions that were designed only for human operators to manually use. I decided from the get-go to make ease of integration a key selling point for my solution. This selling point has been the largest contributor to our growth.

There are two main ways our customers integrate our solution:

1) The functionality is made available in a centralized system for ease of access and control (e.g., a control panel at a hosting company).

2) Monitoring solutions, such as Nagios, that can tell you whether or not a server has crashed or a server is overheating, take automated recovery steps to either correct the problem or prevent escalation of the problem by sending commands to the WebReboot.

Our customers obtain financial benefits by making the relatively simple hardware functionality of our solution accessible in larger systems such as control panels and monitoring solutions. The problem for me was enabling this integration faster and cheaper than the competition.

Our competition, for the most part, chose the route of either developing and maintaining client libraries to manage communication to and from their embedded systems in Java, PHP, Python, etc., to ease integration for their customers, or left the customer to develop solutions on their own. I did not and still do not have the resources to develop and maintain client libraries for my customers. It’s code generation that has enabled me to compete on this level.

For my application, as well as numerous other embedded applications where the interface is tightly coupled to physical hardware, where the means of control on the physical world (e.g., physical relays and sensors, embedded systems) remain largely unchanged over time (it’s very cost-prohibitive to change), where scalability is not a major concern, and where capability and ease of integration are key selling points, WSDL and SOAP may be just what the doctor ordered, even if the only reason is code generation.

Clearly, those that put forth WS-* had much grander ambitions. I firmly believe REST is better suited for obtaining those ambitions. But I also believe this approach has a real future in making it easier and more cost effective for people to bridge the gap between software and the physical world.