Ivory tower protocol wars

There seem to be a lot of blog entries at the moment arguing over the relative merits of XML, JSON, YAML, S-Expressions, etc. as a data interchange format, and Web Services, WS-* Services and REST-style as the application protocol implementation. But while various articles make interesting academic points about which format is more human readable/easier to parse/represents numbers natively/allows cyclic object graphs/clarifies the use of white space/whatever, it’s all pretty much irrelevant in the real world.

What you should be looking for is the easiest thing to implement and maintain on the server, and to use by the intended clients, while still providing the required facilities.

The de-facto implementation choice should be SOAP-based web services, because just about every development platform in the world has a standards-compliant XML reader/writer so can call them fairly easily. Sure, the SOAP envelopes are a little verbose, but in return you get automatic documentation and validation in the form of WSDL/XSD, a defined failure mode with the Fault message format, and in most environments you won’t have to worry about the envelopes anyway thanks to automatic proxy generation which enables you to program against remote services as easily as normal objects. I’m not saying web services are perfect, but all things considered they’re a pretty good choice.

There are of course some cases where you may want or need to step away from SOAP web services.

If you’re implementing an internal communication channel then you might need additional facilities such as distributed transaction flow. In the unmanaged world or .NET pre-3.0 this would likely mean either creating a COM+ Serviced Component or even using Services Without Components. In .NET 3.0 or later this is still a valid approach, but it’s easier to create and manage WCF services using WS-AtomicTransaction, because you can write them just like normal web services and then enable transaction flow using a couple of attributes.

Also for internal channels you may wish to improve performance and reduce the amount of network traffic, which might mean you would prefer to swap XML for a binary format. In .NET 1.0/2.x this would possibly have led you to use .NET Remoting which uses a proprietary communication protocol to achieve significantly better performance than web services. With .NET 3.0 and later you’d be much more likely to use WCF and set it to use the proprietary binary infoset message format, safe in the knowledge that you can easily expose the services as regular XML should the need ever arise in future.

If you’re writing services to be consumed by a client via Ajax then it probably makes sense to use JSON as the interchange format because it is more concise, can be trivially interpreted as a JavaScript object on the client site, and is much quicker to parse than XML due to its more restrictive specification - all of which means that the apparent latency is reduced from the perspective of the user. Since .NET 3.5 there has been a JavaScript serializer</a> (actually, two JavaScript serializers) as part of the framework, though it wouldn’t be hugely difficult to write one for earlier framework versions or other platforms. Use of JSON precludes use of SOAP services so you’re most likely to use a REST-style application protocol for the services themselves.

One apparently popular option that I really don’t comprehend is REST/XML. The services are no easier to call than SOAP web services even if you’re constructing the requests manually because you still have to have a standards compliant XML reader/writer, and you still have to construct and interpret the payloads. You lose the ability to self-document</a> and thus the ability to automatically create proxies which mean you can’t simply generate and serialize objects to construct the requests, and you lose the well defined error message format. And you can’t rely on proxy servers or firewalls to handle all the HTTP verbs such as PUT or DELETE so you might need to add non-standard headers anyway. In return all you get is not having to wrap the payloads in SOAP envelopes and “friendly” URLs, neither of which matter to the computers calling the services anyway because they’re, well, computers. This just doesn’t seem like a fair trade to me.

At blinkbox we use a mixture of XML, JSON and proprietary binary messages with a combination of WS-* services, .NET Remoting, web services and REST-style services, because in each case it is the interchange format and application protocol that is most suitable for the endpoints. It doesn’t matter that WS-AtomicTransaction is massively complex or that JSON is simple; because we chose a set of standards supported by the endpoints we never have to deal with the protocol or on-wire format directly. We can just get on with writing the code that actually does something interesting with the information using its native language representation.

There is no silver bullet for formats or protocols; only formats and protocols most suitable for a given situation. Anybody who doesn’t realise this has clearly forgotten what it’s like to be a real-world software developer. Come down from your ivory towers and join us.

blog comments powered by Disqus
Fork me on GitHub