I'm having a hard time tracking down whether the latest Google Sheets and Google Drive APIs support conditional HTTP requests.
I'd like to only apply updates to resources if the resource's state matches the expected state, otherwise I need to pull in changes, and then retry my update.
Any pointers would be appreciated, thanks!
I've read through the docs and performed a fair number of searches, but haven't come to any "yes" or "no" answers.
Related
I'm trying to make my own Google Assistant Actions.
I would like to ask a question. SQL Server is the data source for this. Google Assistant is searching my SQL Server for results. When it finds the result, it reads out the result. Would this be possible? Where can I search or read for more information about how to do this?
What you are looking for is called Actions on Google broadly. Specifically, you're looking to build a conversational action where the user can ask questions that match Intents that you provide to the Assistant to match. When an Intent is matched, the information is passed to your code, which is running as a webhook, to generate a response.
Your webhook can do pretty much whatever you want, as long as you do it quickly enough (in about 5 seconds) and return a response. This can include database queries or any other processing or business logic necessary. Details about doing so for SQL Server are out of the scope for this particular question - but it should be very similar to doing SQL Server queries from any other server you're running.
Playing around with the Github API, I see that there is a limit of 5,000 requests an hour. Is there a way to increase this? (Not the main question)
When I hit the /users/:username/events endpoint, I get back an array of events. The ones that are PushEvent have an array called commits. Each commit has its own endpoint that I can hit to pull more data.
This racks up requests super quickly and I was wondering if there was a better way to do this.
Thanks!
This limit is in place to prevent a single user from using too many resources, so it's not likely that it will be raised. If you want to make one request for multiple events, you can do that with the v4 GraphQL API. Note that the API limits are different for the v4 API and are scored based on points, but it's possible that you may be able to structure your query so as to be more efficient and allow you more data to be fetched.
This answer explains how you can write a GraphQL query to inquire about multiple objects with one request.
There may be alternative ways to get the information you want. For example, if you want to know about push events as they happen instead of after the fact, you may be able to set up a webhook, which isn't rate limited.
As Sendgrid's documentation makes clear, their web GUI activity page is only searchable for the past 7 days.
How do I search for activity from farther in the past?
Web API documentation is here, but I can't find anything about just plain searching for info on sent emails. All I see are endpoints for seeing particular categories of emails' various fates, like blocks, bounces, invalid emails, and "filters", which seem like actions and not like filters.
It's got to be possible to just find info about some particular sent email, right?
It's not possible. As you noted, the documentation clearly states that:
Email activity only shows the most recent 7 days. To access data in
real time, we recommend that you consider implementing our Event
Webhook.
If you want to record all the history associated with your account you should record and save it yourself. You can record all the emails you send provided you have an endpoint to do so. See here: https://sendgrid.com/docs/User_Guide/Settings/parse.html
Later Edit:
"real time" means "as it happens", it does not mean "history searchable at any point in time".
When you use an API, as a developer, the responsibility to log all API calls and responses lies with you. While it's true that bounces aren't necessarily reported in the API call response, the SendGrid API offers several ways in which you can be notified. Personal opinion: I know this functionality is often omitted in the MVP because you need to go to market as soon as possible, but an ELK stack is not that hard to set up.
There are several ways you can look for bounces and other events as you can see here: https://sendgrid.com/docs/Classroom/Track/Bounces/bounce_reports_how_can_i_be_notified.html
Webhook for events: http://sendgrid.com/docs/API_Reference/Webhooks/event.html
Enabling Bounce Forwarding on your account
Bounce API: https://sendgrid.com/docs/API_Reference/Web_API_v3/bounces.html
If you really need to find out what happened on day X with email send Y, you can contact their Support team. They can probably look it up for you.
Personal opinion:
That 7 days is not a random number. I'm willing to bet that SendGrid does in fact log all calls you made but it can't provide them for an earlier time. When you use Facebook API, Twitter API, etc. You don't expect them to provide you with historical data of every API call you made. This is an ungodly amount of data. We're talking about an API that is used to send probably upwards of millions of emails per day, maybe even more. I believe they actually did the math and recalling historical data from earlier would put an unnecessary strain on the system, it would take a long time to answer such a request.
I'm sorry if I went on a bit of a rant but people often don't think about the volume of data needed to store such things and how much it would cost to search it.
Cognitive Service Recommendation API of Upload Usage Event method does not work well.
Implementation Technique
I was created in the order of the ”model” · ”catalog” · ”file” · ”build” in Cognitive Service Recommendation API.
Response of ”Upload Usage Event” is status code is successful in 201.
I call the ”Update model”.
I call ”Download usage file” and ”Get item to item recommendation”.
The item of ”Upload Usage Event” I tried to make sure it is reflected.
However, it did not reflect.
I want to know how to reflect the item of Upload Usage Event to Build.
Am I wrong what implementation procedure?
After [updloading a usage event][1] you need to create a new build in that model for the usage event to be considered as part of the recommendations request.
Note that a single usage event may not significantly change the model. Usually you retrain the model once a week (or more or less depending on the level of traffic you receive) -- and at that point you would have had sent hundreds or thousands of usage events that may actually impact the model.
My service requirements and business workflows are bit complicated. First, please consider the two different options below.
In my case, the problems going with restful option are
In the restful option, basically to distinguish the operation intended, I
need to inspect the input payload. So, my controller logic is going to bit ugly.
For each of these operation, I need to check for specific roles and permissions. Based on the input payload, I need to check whether the user has the required permission first, rather than having it at the controller method level as we do now in the RPS style.
For some operations, I need to check the current status of the order. For example, approving or rejecting an order which is currently in draft status doesn't make sense. Before approving and disapproving, the order should be in pending for approval status. So, I need call DB to check the current status and this will impact the performance.
Monitoring and perf profiling are going to very complex with restful option in my case.
Trouble shooting production issues going to be complex. Because the input
payload needs to logged and inspected. The http verbs needs to be inspected.
I don't think restful way is making it simple just because of exposing fewer endpoints. Now, clients of this service has to be given clear documentation
explaining what input they have send in order to perform a specific
intended action.
My service is not a simple content delivery applications with fewer operation. In the future, I may need to support more operations than what I have today.
Please don't tell me, I can pass the operation to be performed in the request header. I don't think, it solves all of the above problems.
So, now why should I bother making my service restful?