Thread starter
John Mulcahy
I don't think an openapi 3.0.0 version declaration will cut this. The spec has properties as
host, basePath, schemes, definitions which are swagger 2.0 definitions and are not accepted by openapi 3.0.0 standard.// YAML version swagger doc
post:
tags:
- "generator"
description: "Send a command to the generator "
parameters:
- in: "body"
name: "body"
description: "Body object description"
required: true
schema:
$ref: "#/definitions/Command"
responses:
"200":
description: "successful operation"
schema:
$ref: "#/definitions/APIResponse"
responseSchema:
$ref: "#/definitions/APIResponse"runtime.APIError{OperationName:"[POST /generator/command] PostGeneratorCommand", Response:client.response{resp:(*http.Response)(0xc000126630)}, Code:202}
Where things will take time it seemed more appropriate to respond with 202, any opinions on that? SparkSwagger hardcodes the entries as 200, but I can easily update the code to add 202 entries where they can occur.
thanks for the guidance, I am now able to execute some commands.
No, I haven't implemented any export endpoints.
/measurements/{id}/frequency-response as Base64 strings. It is straightforward to turn those back into float arrays but that needs software, here's how that is done in Java, for example: public static float[] decodeArray(String base64Encoded) {
return byteToFloatArray(Base64.getDecoder().decode(base64Encoded));
}
private static float[] byteToFloatArray(byte[] bytes) {
FloatBuffer buf = ByteBuffer.wrap(bytes).asFloatBuffer();
float[] floatArray = new float[buf.limit()];
buf.get(floatArray);
return floatArray;
}thanks for providing this alternative.
Yes 202 is the appropriate and common response for POST requests.
Maybe, but APIs are for software to talk to software so there doesn't seem much point in writing the data to a file when it can be retrieved directly.
that makes sense. Playing around with /measurements/{id}/frequency-response endpoint and postprocessing the u64 string is giving quite weird results (at least comparing to what I exported manually to txt).
The
resultUrl is optional and can be set as address for the results to be posted to. If not needed, you can omit it in your request.
The data is Base64 encoded float32 values, not u64.
The latest beta release links are in the first post of this thread. You misunderstood the release comment, it is not possible for REW to select the height channels of an AVR.
Please use the Generate diagnostic file option in the Help menu and attach that file and the measurement you had loaded when you encountered the issue.
Beta 4 was already there. Beta 5?
Not related to APIs but is it viable to include previous RAM allocation when "update existing installation" is selected during new REW updates? If a custom RAM allocation above 3GB is used, it needs to be updated manually in the options file each time.
