Operations
These intent resources provide some basic functionality to interact with consumer provided configurations.
These intent resources provide some basic functionality to interact with consumer provided configurations.
Authorization | Bearer {access_token} |
Content-Type | application/json |
Accept | application/json |
Check the buildability for a given configuration.
The response contains the information whether the given configuration is buildable and
distinct. When the Parameter "complete" is set, the response also contains the information wether the configuration is complete. The Defintion of complete is explained beneath at this location: Status “complete” of Configuration
A configuration is buildable if the configuration defines an assortment of options, that can
be contained in one or more vehicles which can be produced
So what do we mean if we talk about a distinct configuration: If you provide a partial configuration, and the combination of options is buildable, there might be several options, on how a car could be build.
A distinct configuration defines enough options to make out just one vehicle. We will always try to autocomplete a partial configuration, but in order to identify a single buildable vehicle we need as many options as it takes that there could be just one version of a vehicle left: In the example the selection of the red hubcap just leaves one option to build that vehicle.
Example Request with cURL
A distinction can be made between a buildable, a distinct configuration and a complete configuration. A buildable configuration is then given, when all the necessary parameters for a buildable vehicle have been met. With a distinct configuration the condition is that all Options are set as well as these are not indirectly derivable (e.g. missing option, which has no alternatives). A configuration is complete, if all necessary options are set (e.g.options must be selected to a certain product, like for example with a navigation system also the USB socket is needed).
The attribute "complete" indicates whether all customer-selectable options together with the country settings represent a complete order in the configuration. The reverse is also true, if the configuration is distinct but further customer-selectable options would be forced, then this configuration is "complete=false”.
Authorization | Bearer {access_token} |
Content-Type | application/json |
Accept | application/json |
Request the WLTP values for a configuration. In order to request the WLTP values the given configuration has to be distinct. You can always call the check resource in order to assure that the configuration is distinct, before issuing a call to request the WLTP values.
Example Request with cURL
Authorization | Bearer {access_token} |
Content-Type | application/json |
Accept | application/json |
To complete a partial configuration to a fully equipped and buildable car, you can use the
resolve
function of the options endpoint.
We will amplify the given set of options with a selection of options that will make your
current partial configuration
a distinct one.
The request responds with a completed and distinct configuration.
The options added to the configuration's set of options will provide just one random example
of how a partial configuration might be extended to gather a distinct configuration.
If your configuration has already been distinct the response will just contain the given
configuration. Please note that your configuration has to be buildable.
Authorization | Bearer {access_token} |
Content-Type | application/json |
Accept | application/json |
To recover a given configuration that is not buildable, okapi will search for options that are conflicting with your current selection of options but valid options within the model. The request responds with a recovered configuration. If the configuration contains options, that are not valid within the given model, the resource will respond with a 409.
Authorization | Bearer {access_token} |
Content-Type | application/json |
Accept | application/json |
At every point within the configuration process you can request the list of choices. A choice contains options that are either valid or invalid within the current configuration. Beside this information a choice defines a category/domain of a given configuration that can be customised with options that are provided.
OKAPI allows prioritizing the options in the requested configuration. Depending on the use case, options can be sorted into the input-categories listed below. They have different effects on the solutions/configurations you get as response. At /solutions-endpoint you see difference of your input configuration+parameters as add_options and remove_options. Below is a description of each field with an example.
Field | Description | Example |
---|---|---|
preferred_options |
|
v3/operation/DE/solutions?preferred_options=PACKET:WBA+MIK:3D7
|
nice_to_have |
|
v3/operation/DE/solutions?nice_to_have=PACKET:WBA+MIK:3D7
|
one_of |
|
{
|
none_of |
|
{
|