Current:

try {
  await schemaFacade.validateContractSchema(projectRevision, contract);
} catch (err) {
  assert.include(err.message, "Could'nt find any non-empty");
}

which doesn't fail the test if no exception was thrown, which is incorrect.

From @rm-hull on Jun 29, 2017, 9:53 AM GMT+2

For example, the report as is, it is quite difficult to see what is making the contract fail:

provider-client-services:contracts/ @ bfb5911a54122b89c61a877858a2b8227200962b is not valid: 

Consumer [ bpc-libs:bpc-transaction-store/contracts/ @ master ] expectations of type (rest) is broken: 
============================================================================ 
Expectation broken: 

 { '/session/store/{sessionId}': 
   { get: 
      { produces: [ 'application/json;charset=UTF-8' ],
        parameters: [ { name: 'sessionId', in: 'path', required: true, type: 'string' } ],
        responses: 
         { '200': { description: 'OK' },
           '404': { description: 'Not Found' } } },
     put: 
      { consumes: [ 'application/json;charset=UTF-8' ],
        parameters: 
         [ { name: 'sessionId', in: 'path', required: true, type: 'string' },
           { name: 'data',
             in: 'body',
             required: true,
             schema: { type: 'string' } } ],
        responses: { '200': { description: 'OK' } } } } } 

is not a subset of: 

{ '/health': 
   { get: 
      { tags: [ 'health-controller' ],
        summary: 'Health check',
        operationId: 'healthUsingGET',
        consumes: [ 'application/json' ],
        produces: [ '*/*' ],
        responses: 
         { '200': { description: 'OK', schema: { type: 'string' } },
           '401': { description: 'Unauthorized' },
           '403': { description: 'Forbidden' },
           '404': { description: 'Not Found' } } } },
  '/session/store/{sessionId}': 
   { get: 
      { tags: [ 'transaction-storage-controller' ],
        summary: 'Fetch a transaction',
        operationId: 'getUsingGET',
        consumes: [ 'application/json' ],
        produces: [ 'application/json;charset=LATIN-1' ],
        parameters: 
         [ { name: 'sessionId',
             in: 'path',
             description: 'transactionId',
             required: true,
             type: 'string' } ],
        responses: 
         { '200': { description: 'OK', schema: { type: 'string' } },
           '401': { description: 'Unauthorized' },
           '403': { description: 'Forbidden' },
           '404': { description: 'Not Found' } } },
     put: 
      { tags: [ 'transaction-storage-controller' ],
        summary: 'Store a transaction',
        operationId: 'putUsingPUT',
        consumes: [ 'application/json;charset=UTF-8' ],
        produces: [ '*/*' ],
        parameters: 
         [ { name: 'sessionId',
             in: 'path',
             description: 'transactionId',
             required: true,
             type: 'string' },
           { in: 'body',
             name: 'data',
             description: 'data',
             required: true,
             schema: { type: 'string' } } ],
        responses: 
         { '200': { description: 'OK' },
           '201': { description: 'Created' },
           '401': { description: 'Unauthorized' },
           '403': { description: 'Forbidden' },
           '404': { description: 'Not Found' } } } } }

It might be better to show a diff for each identified mismatch, something along the lines of:

Expected: '/session/store/{sessionId}' --> get --> produces --> 'application/json;charset=UTF-8' 
Promised: '/session/store/{sessionId}' --> get --> produces --> 'application/json;charset=LATIN-1'

From @rdsubhas on May 19, 2017, 11:23 PM GMT+2

What we need?

• Client library for the given provider contract
• Must: Logging and Monitoring (log every call that's being made, measure response times, use standard metrics naming conventions)
• Must: Client identification (User agent), Request IDs (generate a request ID header if not present) and other stuff
• Must: API/Endpoint Versioning, Artifact versioning. both are different, each API call/entity/operation can have versioning - i.e. v1 POST booking, v2 POST booking. But at the same time, the entire client library can get a major version bump when we create dependency conflicts - i.e. we upgrade dependency versions like okhttp/swagger/hystrix/etc (e.g. protobuf-commons upgrades major versions when protobuf version changes). API by itself has no version - only endpoints have multiple versions and independent breakages per use-case. But the library itself has a technical version that can be incompatible and be bumped up as a whole
• Must: Java (duh)
• Optional: NodeJS (untyped, not much use having a client library)
• Optional: HTTP/2 support, persistent connections, performance tuning
• Optional: Exponential backoff/retry for specific cases (i.e. don't try retrying "creating a booking", define some client response codes that will be retried, e.g. server is not available or not found, idempotent GET requests, non-4xx responses, etc), circuit breaker
• Optional: Service discovery (let the provider define their ingress URL using some format, either use kubernetes service names, or just provide some default service discovery)

Artifact lifecycle

1. notary simply generates and publishes client libraries upon every commit to projects, directly to our nexus
2. notary act like a nexus repo, and on-demand generate client libraries and returns them
3. a /publish endpoint in notary, and if anyone calls that, the client libraries will be generated and published

Approach/Design

• Use swagger codegen as the ideal model
• Follow their Modifying the client library instructions
• Adapt it to our workflow

..... in progress

A RESTful API so 3rd-party tools/users can query contracts by:

• Name
• Meta Data
• Project
• Type
• Upstream

Resources:

• Project
• Contract

The same API should be used for the upcoming fat client-side Directory GUI.

When we have several different consumer expectations, execute all of them and create a report with both passing and failing expectations.

From @omarahm on May 21, 2017, 2:18 PM GMT+2

What is the problem?
The current algorithm for fetching consumers is as follows:

1. Get all promises for the project under test
2. Loop through all of the registered projects and check if any has one or more expectations from the project under test
3. Match promises to expectations

If the project under test decides to drop one of the promises, because of the steps mentioned above, the current validation will be green although we have "orphaned consumers".

What is required?
Tweak the current logic to cover the above mentioned scenario.

Resolve all JSONSchema $ref links before validating schema contracts.