Web service interfaces are supposed to define a contract between clients and a Web service. But important service aspects may have to be left unspecified if SOAP or REST are used in defining a service interface, according to Dan Pritchett's recent blog post, You Call it Coupling, I Call It Reality.

Pritchett suggests that because neither SOAP nor REST allows a service provider to specify all aspects of a service that clients might come to depend on, client often make assumptions about a service implementation beyond what the service's interface specifies. That, in turn, leads to inadvertent coupling between clients and a particular service implementation, according to Pritchett:

An interface should clearly abstract the implementation. Everyone gets that. But what aspects of the interface are you explicitly stating and what aspects are being implicitly assumed? Is the response time part of the contract? Is the maximum throughput? Perhaps you say no, but then how can you be sure that no application, at Internet scale, has placed a concrete dependency on these aspects of your interface? And if either aspect were to change in a negative way, you'd break those applications.

These questions become especially relevant in the context of Ajax-style invocations of a service— for example, the user interface in the browser often relies on some bounded response time or system availability. In general, a client often has limited ways of dealing with situations where the service implementation fails to fulfill implicit assumptions about the service. Such assumptions create dependencies between client and service, according to Pritchett:

If the goal is to achieve Internet scale, then failing to explicitly define your contracts will lead to real coupling. Non-obvious interactions that make both sides of the contract dependent upon each other and almost impossible to change in any manner at all.

Pritchett notes that to alleviate that dependency, a good interface should specify aspects of a service that neither SOAP nor REST currently allows:

If you're designing a good component with good contracts, then you are specifying aspects beyond simply the call interaction. You are specifying performance, availability, transactional assurances, data retention, manageability, and extensibility to name a few. You have to clearly state what promises you're making in each of these areas. You also have to be clear that those things that aren't specified are to be considered not part of any contract. In some cases, you may even specify aspects of the component that may not be depended upon.

To what length do you think a service provider should go in specify such additional aspects of a service contract? And to what extent do you rely on implicit assumptions about an interface in your code?