Fetching data from one post response and reusing it for two other requests using JSON Extractor in Jmeter.
After reusing the response param for the first request the second request can't reuse the response and shows the default value used in JSON Extractor.
The values aren't coming in the second request, however it comes in the first request.
Most probably your placement of the JSON Extractor is incorrect, JMeter PostProcessors obey JMeter Scoping Rules so if you have the JSON Extractor at the same level as other Samplers - it's getting applied to all samplers therefore after 1st request is being executed the variable gets overwritten with the default value.
The solution is to put the JSON Extractor as a child of the request which returns the data you want to extract, something like:
You should put JSON Extractor level under request 1, and not after, in order to get the variable from response 1 only
This is because it's a post processor which is executed after each Sampler (request) in its hierarchy
The rest service which are fetching parameters and JSON extractor should be kept as a child of the web-service from which parameters are fetched. This solved my issue.
Related
Basically if there is fresh data in the database, I will directly read that data, otherwise if the data is older, I would be computing new data to insert, and then read that inserted data. Which is better, putting that logic under one POST endpoint or splitting the insert part under a POST endpoint, and the get part under a GET endpoint, then calling the POST endpoint which would redirect to the GET endpoint?
Assuming that "computing new data to insert" doesn't involve reading information out of the HTTP request body, you should normally use GET here.
We choose HTTP methods based on the semantics of the request ("give me the current representation of the resource") not on the implementation details of the request handler.
If you don't need to send the data in the request body, then use one endpoint and use GET for it. A similar question involves counting reads of a resource, which has a side effect too, still we use GET for retrieving the representation of the resource along with read count, because the operation is about data retrieval not data sending.
Another reason for using GET, that you will be able to use caching features this way, and using if-modified-since or if-none-match will make what you want a lot easier.
I have implemented an /GET HTTP endpoint to provide search feature. The user sends search terms in query parameters and receives JSON response containing all search results.
Now I have to add a new feature i.e. save search. It means the user sends same search parameters and can also send a boolean parameter say save=true. I have to save the search term in database in this case for future uses. However this parameter is not mandatory.
I am confused over the following points:
Modify same GET HTTP endpoint allowing additional save parameter in query parameters.
Modify same GET HTTP endpoint but passing save parameter in request body instead of query parameters as its backend state changing parameter.
Use separate endpoint for save the parameters using POST method.
What is the standard/acceptable way of doing this?
As far as I understood your question you try to store a search request and by storing it also retrieve the response in one go?
Usually GET is used to retrieve a resources' state though as this method is defined as safe it shouldn't be used if certain state is created for the invoked resource as persisting the search query would be. RFC 7231 further states that:
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.
I therefore would refrain from option #1 or #2 as this might break interoperability by certain clients.
POST on the otherhand is defined in RFC 7231 as
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.
It therefore should be used in every situation the other HTTP operations don't fit. The HTTP spec further defines that creating a new resource a 201 Created HTTP status code should be returned including a HTTP response header named Location containing the URI of the created resource. This URI can later be used to retrieve it's state (i.e. the performed search result).
From a client's perspective you are basically storing some query definition on the server and don't care where or how the server is actually persisting it. All you care is to retrieve a handle you can later on invoke. This doesn't prevent the server from returning the current search result within the response payload. And this is what I'd do exactly.
Proposed steps:
Send search request via POST
Store query definition
Generate the URI for the stored query
Perform the search according to the query
Return a response with a 201 Created status code and Location header pointing to the URI of the stored query and add the query result within the response payload
A client can later on use the returned URI to retrieve the current state of the resource, which the server can interpret as: execute the query stored for that URI and return the search result.
How the URI has to look like is not defined by the REST architecture. You might generate UUIDs or generate a hash value based on the query generate. The latter approach has the benefit that multiple identical queries wouldn't result in additional queries created but in the reusage of such. In such cases a redirect to the existing query resource should be performed to tell the client that his query already existed which also teaches the client the actual URI of the query resource as a side effect.
Is it possible to document a response field for a controller that returns a single value?
Example: [GET] /book/count
JSON Response: 1
You can't use the response fields snippet. It expects a structured JSON or XML response. Given that your response is a single, numeric value I don't think you'd gain much from REST Docs documenting it anyway. There's next-to-nothing for it to document and verify.
REST Docs will still automatically produce an HTTP response snippet that you could use. If you want something more, you could write your own Snippet implementation pretty easily.
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.
What I know that the HTTP method GET is for fetching/searching data and POST is for create/insert data.
But what if there is a case that I want to search data but the parameters (key-value pairs) are so many or big that there is possibility it will go over the query string limit for the GET method.
In this case, if I use POST for searching data, is it valid in the REST or HTTP specification?
Its perfectly valid in the scenarios where you have lot many number of variable parameters.