Foundations for components and service models
Bill de hÓra offers some good guidance on service model evolution:
The core problem of component and service architectures is easy to express: how do I change a published interface without breaking the callers?
I’ve summarized the major points and made some additional notes from a .NET background (with an eye toward REST).
Avoid changing or extending the interface methods
No problem in a REST style, since the interface is uniform. For example, use the already-specified HTTP method set.
Control change by using a dictionary interface
Bill mentions binding functions to names in this dictionary–an interesting thought. Delegates are the closest thing in .NET to a first-class function object. So I think of this as creating a dictionary of delegates, then looking up the function I want by name.
I’m not sure whether this is necessary if you define a uniform interface, ala REST.
Calls should return documents not objects
In the REST style, the document would be a representation of some resource’s state.
Avoid binary compatability
Bill talks to the use of XML Infoset instead of XML in SOAP 1.2.
In the .NET world, I take this as pertaining to object serialization and/or xml serialization. .NET makes it really easy to serialize an object out to binary or xml forms, but if you change one end of the serialization, you have to also change the other. Furthermore, if there are any objects serialized into a peristent store, you have difficulty reading them back in. The easy forms of .NET serialization seem essentially useless for service implementations.
Don’t confuse an API with a contract
Bill suggests modeling contracts as “an ordered exchange of documents”. I don’t fully understand why this is.
Version the contract
in my experience, at the level of components and services, the right approach is to version the protocol and shared data format, and not the API signatures
So, don’t version GET, PUT, POST, DELETE. I’m a little confused as to whether Bill is suggesting that we version the protocol (HTTP) and the shared data format (entity-body format) or the protocol format (message format?) and the shared data format (entity-body format)
Don’t build an API for data transfer
Someone suggested that 80% of a business application is basic CRUD functionality, which is fundamentally data transfer.
But it’s certainly also possible to solve computational problems using data transfer. For example, this solution to the dining philosophers problem.