Trigger extraction jobs endpoint has incorrect OAS3 definition

APIs & Connectors
1

Dear Visier developer community,

After calling the endpoint POST /v1/op/data/startExtractAndLoad we have noticed that the endpoint doesn’t accept application/json request body, but it accepts multipart/form-data. Therefore, this line in the OAS3 spec should be changed to multipart/form-data. Furthermore, the response field jobId in the object definition StartExtractionResponse should start with a capital J letter, namely JobId.

Thanks in advance

2

Hello @b.zafirov ,
Thanks for logging this.

  • The API should be able to handle application/json and an internal ticket has been created for that.
  • Element names, such as jobId are in camelCase by design.

Thanks,
/Henrik

3

Hello @henrik.areskoug,

The API should be able to handle application/json and an internal ticket has been created for that.

Great, please update the OAS3 spec, when the ticket will be processed.

  • Element names, such as jobId are in camelCase by design.

Yes, we are aware of this. The problem here is that the first letter of the field is in capital case, namely it is JobId. Same as other fields the field name should be jobId.

Best regards

4

Hello @b.zafirov ,

The ticket is in the backlog and I can’t provide an exact time when it will be processed. It will be addressed however.

As for the casing, I’m not quite following you on this. Above you said:

Furthermore, the response field jobId in the object definition StartExtractionResponse should start with a capital J letter, namely JobId .

This is incorrect as it should start with a lower-case letter, which it does.

Then you said:

The problem here is that the first letter of the field is in capital case, namely it is JobId . Same as other fields the field name should be jobId .

I’m not sure where you’re finding JobId as an element name. Please provide a line-level link into the file that has the invalid element name.

Thanks,
/Henrik

5

Hi @henrik.areskoug,

Sorry for the misunderstanding. The problem is that the endpoint implementation and the OAS3 endpoint definition are not consistent. When called the endpoint returns the following response:

{
	"JobId": "<VALID-JOB-ID>"
}

And in the OAS3 spec the field name starts with a lower case j (e.g. jobId), as it can be seen here. So the endpoint implementation and the definition need to be consistent.

Best regards

6

Hi @b.zafirov,

My apologies. I finally get what you mean. Yes, that is an inconsistency that will be addressed. I’ll log a bug. Unfortunately, in order to maintain backward-compatibility for the API, the fix will be in the OAS3 definition itself.

Thanks,
/Henrik