anchor.diff:  
   [source,java,indent=0]
   ----
  -Unresolved directive in verifier/introduction.adoc - include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=server_api,indent=0]
  -Unresolved directive in verifier/introduction.adoc - include::{introduction_url}/samples/standalone/dsl/http-server/src/main/java/com/example/fraud/FraudDetectionController.java[tags=initial_impl,indent=0]
  +@RequestMapping(
  +        value = "/fraudcheck",
  +        method = PUT,
  +        consumes = FRAUD_SERVICE_JSON_VERSION_1,
  +        produces = FRAUD_SERVICE_JSON_VERSION_1)
  +public FraudCheckResult fraudCheck(@RequestBody FraudCheck fraudCheck) {
  +return new FraudCheckResult(FraudCheckStatus.OK, NO_REASON);
   }
   ----
   
  
positive.code: 
  [source,xml,indent=0]
  ----
  Unresolved directive in verifier/introduction.adoc - include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=verifier_test_dependencies,indent=0]
  ----
  
  In the configuration of the Maven plugin we passed the `baseClassForTests` property
  
  [source,xml,indent=0]
  ----
  Unresolved directive in verifier/introduction.adoc - include::{introduction_url}/samples/standalone/dsl/http-server/pom.xml[tags=contract_maven_plugin,indent=0]
  ----
  
  That's because all the generated tests will extend that class. Over there you can set up your Spring Context or whatever is necessary. In our case we're using http://rest-assured.io/[Rest Assured MVC] to start the server side `FraudDetectionController`.
  
  [source,java,indent=0]
  ----
  Unresolved directive in verifier/introduction.adoc - include::{introduction_url}/samples/standalone/dsl/http-server/src/test/java/com/example/fraud/MvcTest.java[]
  ----
  
  Now, if you run the `./mvnw clean install` you would get sth like this:
  
negative.code: 
  [source,groovy,indent=0]
  ----
  package contracts
  
  org.springframework.cloud.contract.spec.Contract.make {
  			request { // (1)
  				method 'PUT' // (2)
  				url '/fraudcheck' // (3)
  				body([ // (4)
  					clientId: value(consumer(regex('[0-9]{10}'))),
  					loanAmount: 99999
  					])
  				headers { // (5)
  					header('Content-Type', 'application/vnd.fraud.v1+json')
  				}
  			}
  			response { // (6)
  				status 200 // (7)
  				body([ // (8)
  					fraudCheckStatus: "FRAUD",
  					rejectionReason: "Amount too high"
  				])
  				headers { // (9)
  					 header('Content-Type': value(
  							 producer(regex('application/vnd.fraud.v1.json.*')),
  							 consumer('application/vnd.fraud.v1+json'))
  					 )
  				}
  			}
  }
  
  /*
  Since we don't want to force on the user to hardcode values of fields that are dynamic
  (timestamps, database ids etc.), one can provide parametrize those entries by using the
  `value(consumer(...), producer(...))` method. That way what's present in the `consumer`
  section will end up in the produced stub. What's there in the `producer` will end up in the
  autogenerated test. If you provide only the regular expression side without the concrete
  value then Spring Cloud Contract will generate one for you.
  
  From the Consumer perspective, when shooting a request in the integration test:
  
  (1) - If the consumer sends a request
  (2) - With the "PUT" method
  (3) - to the URL "/fraudcheck"
  (4) - with the JSON body that
   * has a field `clientId` that matches a regular expression `[0-9]{10}`
   * has a field `loanAmount` that is equal to `99999`
  (5) - with header `Content-Type` equal to `application/vnd.fraud.v1+json`
  (6) - then the response will be sent with
  (7) - status equal `200`
  (8) - and JSON body equal to
   { "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" }
  (9) - with header `Content-Type` equal to `application/vnd.fraud.v1+json`
  
  From the Producer perspective, in the autogenerated producer-side test:
  
  (1) - A request will be sent to the producer
  (2) - With the "PUT" method
  (3) - to the URL "/fraudcheck"
  (4) - with the JSON body that
   * has a field `clientId` that will have a generated value that matches a regular expression `[0-9]{10}`
   * has a field `loanAmount` that is equal to `99999`
  (5) - with header `Content-Type` equal to `application/vnd.fraud.v1+json`
  (6) - then the test will assert if the response has been sent with
  (7) - status equal `200`
  (8) - and JSON body equal to
   { "fraudCheckStatus": "FRAUD", "rejectionReason": "Amount too high" }
  (9) - with header `Content-Type` matching `application/vnd.fraud.v1+json.*`
   */
  ----
  
  The Contract is written using a statically typed Groovy DSL. You might be wondering what are those
  