ResolveAndAddByOwnerAndRelationType does not report parameter mismatches

[idg10]

The ResolveAndAddByOwnerAndRelationType extension method for ILinkCollection (HalDocument being the implementation on which this is typically invoked) enables correct generation of links in an resource representation. It is how we normally populate the _links section of a HAL document. It is a "stringly-typed" API because different resources need different numbers of parameters to build up their URIs, meaning there is no possibility of compile-time verification that the correct types of arguments have been supplied. However, it appears that either there is no runtime checking either, or it is failing to work.

To Reproduce

Register a link using a suitable extension method of IOpenApiLinkOperationMap e.g.:

links.MapByContentTypeAndRelationTypeAndOperationId<Skill>("self", GetSkilletService.OperationId);

The operation id at the end will correspond to an operation defined in the service YAML

get:
    summary: Gets a skillet belonging to a chef in an organizational unit
    operationId: getSkillet
    parameters:
    - $ref: '#/components/parameters/organisationalUnitId'
    - $ref: '#/components/parameters/sectionId'
    - $ref: '#/components/parameters/skilletId'

This defines the parameters required to generate a link for this endpoint—organisationalUnitId, sectionId, and skilletId in this case.

In the construction of a HAL document that contains a link of this kind, use the ResolveAndAddByOwnerAndRelationType method to add a link, but fail to provide the correct set of parameters:

response.ResolveAndAddByOwnerAndRelationType(
    this.linkResolver,
    input,
    "self",
    ("skilletId", input.Id),
    // Uh-oh! We've missed out the sectionId.
    ("organisationalUnitId", context.OrganisationalUnitId));

Expected behavior
The ResolveAndAddByOwnerAndRelationType should throw an exception telling me that I've not supplied all of the information required to build a link of this kind.

Actual behaviour

ResolveAndAddByOwnerAndRelationType returns without error, having added an incomplete link—the link will just have nothing in the place where the missing parameter should have gone, typically resulting in a non-functional link.

In an ideal world, it would also type-check the parameter value, and even format-check it where possible. Parameter definitions describe the parameter type, and may include format information too, e.g. this indicates that the skilletId is a string that must be formatted as a GUID:

    skilletId:
      name: skilletId
      in: path
      description: the ID of the skillet related to the request
      required: true
      schema:
        type: string
        format: guid

We might want to make it possible to disable such checking by configuration, e.g., enabling it to be used only for test and debug in performance-sensitive applications.