I'm developing an application in which race conditions could occur when calling the Google Sheets API. This can happen due to multiple separate users executing the same use case with significantly different parameters. All requests from these users are handled separately and asynchronously.
For simplicity's sake I'll refer to these calls as call A and call B. Both being completely different and asynchronous requests. The values written in both calls will be completely different, hence the output in the read calls will return completely different values.
Normal situation:
Write call A
Read call A
Write call B
Read call B
Simultaneous calls:
Write call A
Write call B
Read call A (this now unintentionally fetches the result written by call B)
Read call B
When both actions are executed simultaneously a condition can occur that the write of call B could race the read of call A. This results in malformed output in the read of call A as the parameters of B are used.
Obviously I should improve the applications design by using a queue mechanism, but I'm hoping multiple users have bumped into this problem and that the API has a solution to this issue.
I've been nosing around in the API documentation and couldn't find support for certain cases other than having multiple duplicate sheets and randomising the IDs within my application.
Related
I am currently working on a REST API for a project. In the process I should search for events. I would like to make an endpoint for searching events in a period. That is, specify two parameters with from - to.
For the search you normally take a GET operation. My question is now it makes sense to specify two parameters in the path or should I rather fall back to a POST operation for something like that.
Example for the path /Events{From}{To}
Is this even feasible with multiple parameters?
If you are not making a change on the resource, you should use GET operation.
More detailed explanation:
If you were writing a plain old RPC API call, they could technically interchangeable as long as the processing server side were no different between both calls. However, in order for the call to be RESTful, calling the endpoint via the GET method should have a distinct functionality (which is to get resource(s)) from the POST method (which is to create new resources).
GET request with multiple parameters: /events?param1=value1¶m2=value2
GET request with an array as parameter: /events?param=value1,value2,value3
We(producer for the API) have an endpoint
/users/:{id}/name
which is used to retrieve name for the user 'id'
Now as a consumer I want to display the list of names for users like:
user1: id1, name1
uder2: id2, name2
where I have the ids in input.
In such a case should I make 2(here the list is dependent on UI pagination example 50) separate calls to the API to fetch information or else create/ask the producer to create a bulk endpoint like:
POST /users/name
body: { ids: []}
If later, then am I not loosing the REST principle here to fetch information using POST but not GET? If former, then I am not putting too much network overhead in the system?
Also since this seems to be a very common usecase, if we choose the POST method is there really a need of the GET endpoint since the POST endpoint can handle a single user as well?
Which approach should be chosen?
A GET API call should be used for fetching data. Since browser knows GET calls are idempotent, it can handle some situations on its own, like make another call if previous fails.
Since REST calls are lightweight, we tend to overuse API call repeatedly. In your case, since you want all name v/s id mapping at once, one call is sufficient. Or have a Aggregator endpoint in backend API gateway to reduce network traffic and make repeated calls nearer to actual service.
Keeping GET /users/:{id}/name , is also not a bad idea alongside this. It helps to abstract business functionality. A particular scenario can only allow single fetch.
Also using GET /users/name with pagination and returning list of names is complex for single use so keeping both are fine.
Lets say I have one api and there are different scenarios to check in that one api.So for this can we add different scenarios in one feature file without calling api again and again.
You can certainly have multiple scenarios in one feature file.
And if you get a response back and you can do all the assertions you have in mind against this single response - you don't need to call again. Maybe you need a single scenario.
If you are expecting all your boundary conditions and non-happy paths to be achieved without making multiple HTTP calls, I'm sorry - I don't think any framework will do that magic for you.
I am currently using silverlight to build a control for a CRM form.
There are quite a few asynchronous calls being made where I am retrieving various sets
of data. The problem I am facing however is sometimes the calls are made in a random order
and I need to retrieve the data in a particular order for data binding reasons.
Any idea?
Basically I have 3 Methods -
Retrieve Accounts
Retrieve Opporunities
Retrieve Leads
Each have call backs but I want each to respond with results from callback before moving to the next.
Make the calls synchronous, or
in each call back, invoke the next call
I've been fighting and fighting for some time with a decent way to handle a workflow based on a series of asynchronous ASIHTTPRequests (I am using queues). So far it seems to have eluded me and I always end with a hideous mess of delegate calls and spaghetti code exploding all over my project.
It works as follows:
Download a list of items (1 single ASIHTTPRequest, added to a queue).
The items retrieved in step 1 need to be stored.
Each item, from 1 is then parsed, queuing a 1 ASIHTTPRequest per item, for it's sub-items.
Each of the requests from step 3 are processed and the sub-items stored.
I need to be able to update the UI with the progress %age and messages.
I'm unable for the life of me to figure out a clean/maintainable way of doing this.
I've looked at the following links:
Manage Multiple Asynchronous Requests in iOS with ASINetworkQueue
Sync-Async Pair Pattern Easy Concurrency on iOS
But either I'm missing something, or they don't seem to adequately describe what I'm trying to achieve.
Could I use blocks?
I see myself facing a quite similar issue as I got the exercise to work on a app using a set of async http and ftp handlers in a set of process and workflows.
I'm not aware about ASIHTTP API but I assume I did something similar.
I defined a so called RequestOperationQueue which can for example represent all request operations of a certain workflow. Also I defined several template operations for example FTPDownloadOperation. And here comes the clue. I implemented all these RequestOperations more or less accroding to the idea of http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations/. Instead of implementing the delegate logic in the operation itself I implemented sth like callback handlers specialized for the different protocols (http, ftp, rsync, etc) providing a status property for the certain request which can be handled by the operation via KVO.
The UI can be notified about the workflow for example by a delegate protocol for RequestOperationQueue. for example didReceiveCallbackForRQOperation:(RequestOperation) rqo.
From my point of view the coding of workflows including client-server operations gets quite handy with this approach.