When using the /delta endpoint with Core API and I receive a "has_more" response, what cursor should I pass into the following call to the endpoint? Should I pass my newly received cursor, or the original cursor that I started the request with?
I presume the new response, but I've been unable to craft a request that actually gives me the has_more as part of the response.
You pass the newly-received cursor.
Getting this response for testing should be pretty easy... just make sure you have a few thousand files.
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 am trying to create a simple API using Go that performs certain operations depending on the data provided.
I was planning to provide JSON data to this API and get details from it for further use.
Since I was trying to provide JSON data I created the routing using gorilla/mux as below:
router.HandleFunc("/msa/dom/perform-factory-reset?json={jsonData}", CallGet)
log.Fatal(http.ListenAndServe(":8080", router))
But while trying to hit the endpoint http://localhost:8080/msa/dom/perform-factory-reset?json={"vrf":"ds","ip":"45","mac":"452","method":"gfd"} I am getting 404 page not found error.
Hence I tried to change the implementation such that new routing is done as:
router.HandleFunc("/msa/dom/perform-factory-reset/json={jsonData}", CallGet)
This works absolutely fine and I am able to perform desired tasks. Could someone tell me why this is happening?
Is the router gorilla/mux? If so, you cannot add query parameters to path like that. You have to:
router.Path("/msa/dom/perform-factory-reset").
Queries("json","{jsonData}").HandlerFunc(CallGet)
If it is some other router, then you still probably have to register path without the query parameters, and then get the query parameter values in the handler from the request.
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.
I am working on a restful api and I need to update a resource (i.e. a customer detail record with 10 fields).
On Add request, I send a Post request with complete record.
On update request, I send a PUT request with complete record of 10 fields.
On Verify request, I send a PUT request with just two fields i.e. recordId and versionNo.
On Delete request, I send a DELETE request with two fields in HttpOptions.
I have few questions that:
Although, it a restful api but specific application which would be used by an angular application, So should I return data in response of POST/PUT requests.
Should I use PATCH in case of Verify (or anyother action where just recordId and versionNo send to server to change some fields) or it is OK to use PUT.
To make uniformity, should I send data in body of delete request as I need recordId and versionNo to delete a record.
Should I use PATCH in case of Verify (or anyother action where just
recordId and versionNo send to server to change some fields) or it is
OK to use PUT.
In RESTful API designs, PUT requests are generally used to add or replace an entire resource, whereas a PATCH should be just used to update an existing resource. A PUT request is called "idempotent" - no matter how many times you send a PUT response, you should get the same result. A PATCH is not idempotent.
example:
PATCH /Cars/vauxhall-astra/engine --> This request would be used to only update the engine of my already existing vauxhall astra
PUT /Cars/renault-clio --> This request would create a new Renault Clio or, if it already exists, replace the entire Clio using the data specified in my request. A Clio would then be guaranteed to exist after my request is successful, regardless of whether it existed or not before.
Although, it a restful api but specific application which would be used by an angular application, So should I return data in response of POST/PUT requests.
Totally up to you, returning data from a POST/PUT is fine - especially if it saves you having to make extra GET api requests. Just always make sure you are only ever returning the data you need from a response.
To make uniformity, should I send data in body of delete request as I need recordId and versionNo to delete a record.
Again it's totally up to you. Whether you use query parameters (e.g. DELETE cars?id=123) or a request body is just your preference, there's nothing in REST that has rules for this.
REST Response
A RESTful API MUST always answer with HTTP codes to client requests:
Success and error responses are a vital part to define how an API is used correctly.
Refer to this guide to solve all your RESTful related questions.
PATCH/PUT
From Wikipedia:
The main difference between the PUT and PATCH method is that the PUT method uses the request URI to supply a modified version of the requested resource which replaces the original version of the resource whereas the PATCH method supplies a set of instructions to modify the resource. If the PATCH document is larger than the size of the new version of the resource sent by the PUT method then the PUT method is preferred.
Also:
Using the PUT method consumes more bandwidth as compared to the PATCH method when only a few changes need to be applied to a resource. But when the PATCH method is used, it usually involves fetching the resource from the server, comparing the original and new files, creating and sending a diff file. On the server side, the server has to read the diff file and make the modifications. This involves a lot of overhead compared to the PUT method.[11] On the other hand, the PUT method requires a GET to be performed before the PUT and it is difficult to ensure that the resource is not modified between the GET and PUT requests.
So I will use PATCH for verifying a resource.
DELETE
Normaly, for DELETE requests, the client specifies the id of the resource and pass it ass a Path Variable on the URL:
curl -X DELETE http://example.com/resource/{id}
But you can pass a body on the request also. This possibility is stated by MDN Mozilla Web DOCS:
Request has body - May
Successful response has body - May
Even though others have answered the question in details before me but still I'm posting this just to provide a handy short difference between all of these HTTP methods
1.HTTP Post:It is used to create an item
2.HTTP Put:It is used to update an item
3.HTTP Patch:It is used to partially update an item
4.HTTP Delete:It is used to delete an item
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