Closed t880216t closed 5 months ago
Hi @t880216t do you mean instead of using the sitespeed.io cli you want to call the API directly? That part isn't documented by the API is this: https://github.com/sitespeedio/onlinetest/blob/main/server/src/routes/api/api.js
but it has multiple layers of parameter verification
I didn't fully understand how that would stop you from using the CLI to call the API, could you elaborate?
Hi @t880216t do you mean instead of using the sitespeed.io cli you want to call the API directly? That part isn't documented by the API is this: https://github.com/sitespeedio/onlinetest/blob/main/server/src/routes/api/api.js
but it has multiple layers of parameter verification
I didn't fully understand how that would stop you from using the CLI to call the API, could you elaborate?
I can now create tasks by calling the API in the following way, but I don't understand why I have to repeatedly define this url parameter.
curl --location 'http://10.10.58.93:3000/api/add' \
--header 'Content-Type: application/json' \
--data '{
"_": [
"https://www.xxx.com/blog/"
],
"url": "https://www.xxx.com/blog/",
"api":{
"key": "jhde7gFArda33Saa1",
"location": "default",
"testType": "desktop",
"browser": "firefox",
"connectivity": "native",
"iterations": 1,
"label": ""
}
}'
Through analyzing the source code, I found that the parameter assembly method of API interface is different from that of web interface, and some necessary parameters are missing. I have made some modifications to the code and it can be set, but the parameter structure is still not very attractive. As shown in the following example:
{
"api":{
"key": "jhde7gFArda33Saa1",
"location": "default",
"testType": "desktop",
"extras": "--viewPort 1920x1080",
"scriptingName": "",
"scripting": "",
"label": ""
},
"url": "https://www.xxx.com/blog/",
"browser": "chrome",
"browsertime": {
"iterations": 1,
"connectivity": {
"profile": "native"
}
}
}
I think you mixed how things internally are sent. If you run sitespeed.io --help
and look under the API you can see what configuration that is needed to talk to the servers. The rest of the configurations (how tests actually runs) are passed on using the normal setup.
Hey Peter,
Just wanted to follow up on this thread regarding the use of Onlinetests API from REST (triggering tests from the command line does not meet a use case/requirement of our deployment). I noticed there are endpoints that can be hit (/api/add
, /api/status
etc) via REST requests and had to make some changes in order to be able to use additional command line parameters when the test is being sent to the server. (attaching an example of a request I make from Postman to trigger a test)
My question is whether there is already support for something like this so that I could easily pass things like the --script
flag with its relevant JS script for collecting metrics in a REST message body as currently this involves lots of escaping and adding it to the extras
key in the JSON body (based on my code changes in the commit above) as an actual command-line parameter.
Hopefully the question made sense :P
Hi @yashgarde I do not fully follow. So if you use --script
the data isn't passed along? It should work that all parameters that you normally pass on to sitespeed.io should be passed on through the API, that should work if you just post the data yourself I think.
hey @soulgalore, the issue with using the --script
in the extras
key within the REST request body is that since it is a Javascript script within a request body, it is difficult escape correctly with quotation etc. Additionally, the way I made this work was by making code changes to the actual REST API endpoints (adding the extras
parameter and passing it through certain functions).
I just want to make sure this is intended and there isn't an easier way to get REST requests to work for triggering tests.
I see that on the server side, it can be called through an API, but it has multiple layers of parameter verification. I need to assemble a post JSON myself. How can I set it up? I would appreciate an example of the parameters. Thank you very much.