Locust seems to be consolidating the request stats based on endpoint, this works fine for POST request because endpoint doesn't change. However, for GET request endpoint can change on every request
ex,
xyz.com/v1/user/<user_id1>
xyz.com/v1/user/<user_id2>
In this case standard stats that we get are not consolidated at entire test level, what we get in the standard report is
xyz.com/v1/user/<user_id1> | request latency details
xyz.com/v1/user/<user_id2> | request latency details
This is not helpful when we have to assess the entire load test. is there a workaround for this?
You can use the name parameter to rename your requests.
self.client.get("/v1/user/" + user_id, name="/v1/user/...")
for details see https://docs.locust.io/en/stable/writing-a-locustfile.html#name-parameter
Related
In J.meter I need to test multiple web-services in single scenario like, after successful execution of service one it will gives session-Id and this session id will take by other services and check it and complete the scenario as per business logic?
It is classic question regarding "correlation" in JMeter. Correlation stands for the process of extracting dynamic data from previous response and passing it to the next request.
Add a JSON Extractor as a child of the first request and define a JSON Path query to extract the session-Id value and and store it into a Jmeter Variable.
Use the aforementioned JMeter Variable as the session-Id for the subsequent requests.
See API Testing With JMeter and the JSON Extractor article for comprehensive instructions.
What is best practice for search in API?
GET + query parameters, example: GET /search?q=phone
GET + parameters in body, example: GET /search {"query": "phone"}
POST + parameters in body, example: POST /search {"query": "phone"}
Don't include a body with a GET request. That's against the spec:
A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
There are tradeoffs between the other two options. GET requests are cacheable, safe, and idempotent. They're also limited in size.
POST requests are not reliably cacheable, safe, or idempotent, and have no size limit. There's also more flexibility baked in - you can later create a filter resource on the server side in addition to returning the search result, and later searches can use that filter, possibly with a GET, although be careful if you allow caching and changes to the filter definition after it's created.
Looking at your specific example, supporting a single "search" endpoint can get messy pretty fast. If you haven't already, I would encourage you to consider other options.
POST requests are considered to change or create data on the server. GET is considered as a "Safe Method" which have no effect on the server database.
Since search requests do normally not change any data you should use a GET request. The limit is at least 2000 symbols (IE) so most of the times you are pretty safe.
Definitely do 1, GET using query parameters. It is much more likely to be cached.
If nothing in the data model changes on the server, your request should be GET. Server ops like logging is OK, but creation of a filter (as another answer suggested), as distinct from a query cache, say, is not.
I want to build a RESTFUL API.
I have a resource with task plans.
The client should request the server to run task such as benchmarking on one of the task plan metrics.
which request should be used. POST or GET?
and what should be the uri?
/api/plans/<id>/run or /api/plans/run/<id> ?
I will go for a POST and since is an action on a specific plan, the url should be plans/id?action=run.
run is not a sub collection of a plan so query param must be used in this case
GET requests are used for reading/getting data. POST requests are for creating data.
If the user just needs to see the results of a benchmark run, I would use a GET request that returns the results of the benchmark method for the plan.
For retrieving a single record, the URL convention is /things/:id, so I would recommend api/plans/:id/run. I also recommend renaming run to something more descriptive, like benchmark or metrics.
We are exposing an endpoint that will return a large data set. There is a background process which runs once per hour and generates the data. The data will be different after each run.
The requester can ask for either the full set of data or a subset. The sub set is determined via a set of parameters but the parameters are too long to fit into a uri which has a max length of 2,083 characters. https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=uri%20max%20length
The parameters can easily be sent in the request body but which which is the correct HTTP verb to use?
GET would be ideal but use of a body 'has no semantic meaning to a GET request' HTTP GET with request body
PUT is not appropriate because there is no ID and no data is being updated or replaced.
POST is not appropriate because a new resource is not being replaced and more importantly the server is not generating and Id.
http://www.restapitutorial.com/lessons/httpmethods.html
GET (read) would seem to be the most appropriate but how can we include the complex set of parameters to determine the response?
Many thanks
John
POST is the correct method. POST should be used for any operation that's not standardized by HTTP, which is your case, since there's no standard for a GET operation with a body. The reference you linked is just directly mapping HTTP methods to CRUD, which is a REST anti-pattern.
You are right that GET with body is to be avoided. You can experiment with other safe methods that take a request body (such as REPORT or SEARCH), or you can indeed use POST. I see no reason why the latter is wrong; what you're citing is just an opinion, not the spec.
Assuming that the queries against that big dataset are not totally random, you should consider adding stored queries to your API. This way clients can add, remove, update queries (through request body) using POST DELETE PUT. Maybe you can call them "reports".
This way the GET requests need only a reference as query parameter to these queries/reports, you don't have to send all the details with every requests.
But only if not all the requests from clients are unique.
I would like to record the various GET requests to my API in a table and use that table as part of the calculation of what to return for future GET requests.
Perhaps the easiest test example would be a GET function that returns the number of GET requests in the last hour.
The REST protocol says that GET requests should only have data returns.
Do I need to POST the request and then GET the results of the same request?
You can easily achieve that with nodejs
You should have the requests saved in a json file or database for example and have another service that returns this saved data.
Take a look at expressjs
Best luck