The (legacy JSON format) example job-spec for Chainlink multi-word responses implies that a request is needed per item in the response. I.e if you have an API that returns all 3 values you're interested in within a single response, you need to call the API 3 times to correctly obtain and return the 3 values, as opposed to calling it just once and stripping out the 3 values from that single API call. Is this a limitation of the first version of multi-variable responses, or can the job-spec be created in a way to only require a single API call?
Both the JSON and TOML formats have this design pattern. In order to collect 3 results, you must make 3 API calls.
Related
I have gone through various REST API documentation. However, I don't have a clear understanding of it. Can someone help me to understand it in layman's terms? How is it different from API being stateful? Why today all the APIs we develop are restful APIs?
Term stateless/stateful is a common term and has the same meaning for Rest API as for anything else.
Stateless means that when you make a call to some entity the response (output) will always depend on your input only. I.e. for any number of calls with the same input you will ALWAYS get the same response. Example: a request of "what is 2 + 2 equals to?" will always get you an answer 4 no matter how many times you ask and regardless if there were other queries in-between your query requests.
Stateful means that the output will depend on your input and some internal state. Example: "Please add 2 to current number that you hold. what is the new number?" (Assuming that the internal state (the current number) is 0). after the first query you will get the answer 2 but after the same query for the second time you will get answer 4 and so forth.
Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. -- Fielding, 2000
Note that this is a constraint on semantics: all of the information that you need to understand the meaning of the request is in the request itself.
Counter example: the LIST command in FTP, where a null argument for pathname "implies the user's current working or default directory" is not stateless -- current working directory is data of session state that the server needs to remember from previous requests.
I am suffering this strange behaviour of ES.
Call scroll search API with SAME scroll_id from many times.
Mostly, the parameter in response named hits.total.value keeps unchanged.
But some time, this parameter changed between 2 sequence API calls.
Of course, SMAE scroll_id are passed with these 2 API call.
Is there any possible situations which would lead to this behaviour?
I want to get multiple store details using Shopify graphql.
I tried like following but getting only current store details.
nodes(ids: ["gid://shopify/Shop/22954311758","gid://shopify/Shop/25747685469"]) {
... on Shop {
id
email
}
}
I know Shopify not provide other shop details like this because of security reason but I am looking for alternative to get multiple store details in a single graphql call.
This is not possible by default because of 2 restrictions:
1) You can't request two different end points ( you will have to request two stores GraphQL end points at the same time )
2) You will need to pass two different Access Tokens in the header request for each store.
In order to achieve this you will need to create a custom GraphQL server that will handle the request from the two different stores and pass them to your request. So in fact you are making two request in the background but your one will be a single one.
In addition if you make a separate GraphQL server you wont get any advantages in speed unless you cache the requests
But I find this solution a massive overkill in the current state of the request in your question. If you require multiply request of a such matter yes, but if you want to decrease a single request instead of making two just make the two instead of reinventing the wheel.
I'm working on a low latency app for telecommunications industry where the main workflow triggered a computation as follows:
Call a REST API (POST /workflow +payload)
REST web app will perform highly parallelized processing in an fast access cache store
the rest call will return a response (maybe a JSON object of 4 or 5 fields)
Now, my initial idea adhering to REST design principles, is to do 2 REST API calls, one that POSTS to trigger the processing, then returns a 201 with the location of the processing result in the header (because my understanding is REST calls can either change or return a resource, but not both), then automatically redirects to the GET call.
Now remember I'm trying to reduce latency as much as possible, and HTTP redirects obviously increase that. Is it OK if I make my POST return the payload instead of redirecting to a GET? What are the implications?
Cheers,
First, a POST is not an idempotent method to begin with, so it not really possible for a POST not to "violate idempotency."
Second, there is no reason a POST may not return a representation of the newly created resource. In fact, according to RFC7231 (one of the new replacements for RFC2616) it may even be cached for subsequent GETS. See section 4.3.3:
For cases where an origin server wishes the client to be able to cache
the the result of a POST in a way that can be used by a later GET, the
origin server MAY send a 200 (OK) response containing the result and a
Content-Location header field...
I am wondering how the each command on a Parse Query counts towards the request execution limits. I am building an app that will need to perform a function on many objects (could be more than 1000) in a parse class.
For example (in JavaScript),
var query = new Parse.Query(Parse.User);
query.equalTo('anObjectIWant',true); //there could be more than 1000 objects I want
query.each(function(object){
doSomething(object); //doSomething does NOT involve another Parse request
});
So, will the above code count as 1 request towards my Parse application execution limit (you get 30/second free), or will each object (each recurrence of calling "each") use one request (so 1000 objects would be 1000 requests)?
I have evaluated the resource usage by observing the number of API requests made by query.each() for different result set sizes. The bottom line is that (at the moment of writing) this function is using the default query result count limit of 100. Thus if your query matches up to 100 results it will make 1 API request, 2 API requests for 101-200 and so forth.
This behavior can not be changed by manually increasing the limit to the maximum using query.limit(1000). If you do this you will get an error when you call query.each() afterwards (this is also mentioned in the documentation).
Therefore it has to be considered to manually implement this functionality (e.g., by recursive query.find()) which allows you to set the query limit to 1000 and thus, in the best case, only consumes one-tenth of the API requests query.each() would consume.
This would count as 1 or 2 depending on :
If it is run from cloudcode function =2,when 1 is for cloudcode call + 1 for query. Since queries get their results all at once it is single call.
If this should be place within "beforeSave" functions or similar then only query would be counted, 1 API call.
So you should be pretty fine as long as you don't trigger another parse API for each result.
I would not be surprised if the .each method would query the server each iteration.
You can actually check this using their "control panel", just look at the amount of requests beeing made.
We left Parse after doing some prototyping, one of the reasons was that while using proper and sugested code from the parse website, I managed to create 6500 requests a day beeing the only one using the app.
Using our own API, we are down to not more than 100.