Once I have performed sheet = client.open_by_key('GoogleSheetKey').get_worksheet(0) does sheet.cell(1,1) perform another HTTP request to Google API? or is it working off a local object at that point? Thanks!
Yes, sheet.cell(1, 1) performs another HTTP request. This is by design: gspread is a "thin" API wrapper and leaves data caching to the end user.
However, if you modifying multiple cell values, consider batching the updates with Worksheet.update_cells method.
Related
I'm currently developing an app in Laravel. While trying to adhere to REST API guidelines I've come across a scenario that I'm not sure how to handle RESTfully.
I have a Lease resource that handles multiple actions:
Route::get('/lease/create', 'API\LeaseController#create');
Route::get('/lease/{leaseId}', 'API\LeaseController#show');
Route::post('/lease', 'API\LeaseController#store');
Route::patch('/lease/{leaseId}', 'API\LeaseController#update');
Route::delete('/lease/{leaseId}', 'API\LeaseController#destroy');
So far these are a 1:1 between the URI and the controller actions. Now I have additional operations that I need to perform on a Lease and this is where I'm not sure what the best way to handle this is.
1) A Lease can be renewed (clone existing lease with new start and end dates).
2) A Lease can be ended (status changed to Inactive, end date updated).
When I think about doing this RESTfully I look at these two additional operations as a post and a patch to existing endpoints (both would map to the store and update method on the controller and could use the existing URIs.
Should I continue to think about it that way and map them both to existing endpoints? My concern with that is how would I handle different responses? For example if after a renew operation completes I want to pass a message saying "This lease has been successfully renewed.", how would I differentiate between a renew operation and a regular store operation since they both hit the same end point?
Or should I create two new URI's, something like:
Route::patch('/lease/{leaseId}/end', 'API\LeaseController#updateLeaseEnd');
Route::post('/lease/{leaseId}/renew', 'API\LeaseController#storeLeaseRenew');
And control logic in two separate functions even though it would be somewhat redundant since they really are just additional stores and updates?
It looks like you are trying to fit a RPC style API into a RESTful style API, which is possible, but can be confusing. You could do like you were saying with using the PATCH method, but now you have an overloaded method that should only do a partial update, but now it might execute an action on the resource. That would be confusing.
One way I've seen this done is by using what is called a verb (not to be confused by the "HTTP Verb") in the URI. This is essentially what you were stating as your last option in the question.
Structure
https://api.domain.com/namespace/resource/_verb
https://api.domain.com/namespace/resource/{id}/_verb
Example
https://api.domain.com/namespace/lease/{id}/_end
https://api.domain.com/namespace/lease/{id}/_renew
The underscore is there to signify that this is not a resource, but rather an execution call.
Another option would be to separate your REST API from your RPC API. You could use the traditional SOAP web service or go with the new gRPC, by Google.
I want to log the post values of some variables. Depending on what every user with a valid API keys requests the price should be calculated.
Let's say I want to save how often the user requests for ?qualitiy=high and ?quality=low so I can do something like billing = high * 1 + low * 0.5
I connected the api gateway with Cloudwatch to log every request and it logs everything so I would be able to calculate the price with a script running over the entries. But there is no way to define what the logger should save so there is a huge overflow.
Another idea was to put a lambda function before the request is going to the api where I can extract the necessary information from the request and save it to another place. But I don't know where I can place it. I was thinking about writing an own Authorization function and handle it there.
So is the best way to handle such a case to abuse the authorization function to inspect the request and save some information?
An authorizer may be a bad fit for this situation as you will not have access to the full request.
You can simply use the Lambda proxy integration, do your processing, then call your downstream API from within the Lambda. This would not be disimilar to the existing proxy Lambda mentioned in this blog post.
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...
What are the strengths of GET over POST and vice versa when creating an ajax request? How do I know which I should use at any given time? Is it a security-minded decision?
Also, what is the difference in how they are actually sent?
GETs should be used for idempotent operations, that is operations that can be safely repeated more than once without changing anything. Browsers will cache GET requests (for normal and AJAX requests)
POSTs should be generally be used for non-idenpotent operations, like saving something. Although you can use them for other operations if you want.
Data for GETs is sent over the URL query string. Data for POSTs is sent separately. Some browsers have a maximum URL length (I think Internet Explorer is 2048 characters), and if the query string becomes too long you'll get an error.
You should use GET and POST requests in AJAX calls just as you would use GET and POST requests in normal calls. Basic rule of thumb:
Will the request modify anything in your Model?
YES: The request will modify (add/update/delete) data from your data store,
or in some other way change the state of the server (cause creation of
a file, for example). Use POST.
NO: The request will not affect the state of anything (database, file system,
sessions, ...) on the server, but merely retrieve information. Use GET.
POST requests are requests that you do not want to accidentally happen. GET requests are requests you are OK with happening by a user pointing a browser to via a URL.
GET requests can be repeated quite simply since their data is based in the URL itself.
You should think about AJAX requests like you think about regular form requests (and their GET and POST)
The Yahoo! Mail team found that when using XMLHttpRequest, POST is implemented in the browsers as a two-step process: sending the headers first, then sending data. So it's best to use GET, which only takes one TCP packet to send (unless you have a lot of cookies). The maximum URL length in IE is 2K, so if you send more than 2K data you might not be able to use GET.
http://developer.yahoo.com/performance/rules.html#ajax_get
I am attempting to implement a firefox extension which filters incoming HTTP responses and handles them accordingly.
I wish to block HTTP responses containing a specific header. Having read through some of the MDC articles, it appears the most common way of observing HTTP responses is by registering an http-on-examine-response observer.
My question is: Using this observer, is it possible to block the HTTP request from further processing (as a by-product, the page will continue to wait for a response)? Or do I need to use some other facet of XPCOM (if so, care to point me in the right direction)?
Thanks in advance,Mike
Should be possible: the "subject" of that notification is a HTTP channel, on which you can call nsIRequest::cancel().
the page will not continue to wait for a response, though, since you blocked the response. Perhaps you've been actually looking for a way to alter an HTTP response?