Support Query Parameters for Backend Systems

[juliapampus]

As discussed with @jpieperbeck and @ronjaquensel.

Problem: Most APIs are based on specific query parameters for API calls. There is a need for connecting an IDS connector to such parameter-driven data souces. Contrary to how the DSC currently works, it is rather non-economical to create one IDS resource per one possible access url (including fixed query parameters). Instead, the data consumer must be able to somehow "control" the backend API of the provider within its data request.

Target implementation (first draft):

The data provider has to add an endpoint description to the resource. Therfore, we will use the ids:EndpointDocumentation attribute of ids:Endpoints. Problem with this approach: The ids:EndpointDocumentation describes a resource's connector endpoint, which is not the actual underlying endpoint of the backend system. This raises the question of whether the API description is correctly placed at this point. In addition, the API description has to be accessible to the consumer somewhere. For a first implementation, this will be ignored.

The source object needs a documentation attribute that is mapped at IdsUtils::getAsResource for the ids communication.

The data consumer passes query parameters and headers within an ArtifactRequestMessage as a key-value-map. Currently, the payload is empty, so we can easily use it. A request could possibly look as follows:

{
     "params": {
          "key": "value",
          ...
     },
     "headers": {
          "key": "value",
          ...
      }
}

1. Add a parameter for the consumer's query as @RequestBody at RequestController::requestArtifact. Pass it as payload to the ArtifactMessageService when sending the message.
2. Modifications in the ArtifactMessageHandler need to read the payload and pass it to the ResourceService to then implement its interpretation at HttpUtils::sendHttpsGetRequest. Either check for query parameters or add an extra source type in advance.