1

Consumer-Driven Contracts: A Service Evolution Pattern presents the idea of contracts verification.

But how detailed is the contract?

  • Is the contract defining only a syntax of requests/responses? Like WSDL in the case of SOAP Web services.

  • Or does it describes also the order of messages, i.e., the protocol? e.g.:

FIPA-Subscribe-Protocol

  • Or does it define also the behaviour of a system? In other words if I send request R and system is in state S I should receive response W? For instance, if I send a request to buy two monitors and the shop has only one monitor I should get negative but when I request only one monitor I should receive a receipt?
1

At the risk of sounding sarcastic, yes and no.

The consumer and provider contracts must define the syntax of requests and responses. If there are dependencies (indicating that the service is probably rather more tightly coupled to other elements than it should be), those must also be defined.

Conceptually and ideally each request/response pair should be independent so that if you are requesting information only available to a known user of the service, the request/response definition includes requiring some authentication token in the request and data returning only if the authentication token passes validation.

Given independence of request/response pairs, the flow of a transaction is driven entirely by the consumer. To use your example of requesting quantity 2 of widget X:

  • User requests 2x widget X
  • Consumer requests 2x widget X
  • Provider returns 2x widget X not available
  • Consumer decides whether the message is a failure (hard break) or not.

A different consumer might choose to implement a different flow:

  • User requests 2x widget X
  • Consumer requests quantity widget X
  • Provider returns 1
  • Consumer notifies user that only 1x widget X can be ordered.

Both are valid consumer contracts with the same provider contract.

  • Ok. So the contract defines both syntax and the behaviour of the service. – dzieciou Apr 21 '17 at 10:15
  • So in your example consumers have different requirements, one expects negative response when requesting too much and another requests returning what's available. Obviously, it's up to service provider to resolve this requirements conflict and choose which contract the service should support. – dzieciou Apr 21 '17 at 10:18
  • @dzieciou - yes, that is the point of the consumer-driven contract. Each consumer decides how to interact with the provider's contract, using a preferred flow and subset of the provider's API – Kate Paulk Apr 21 '17 at 11:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.