A recent Ars Technica article rekindled my interest in WebOS so I was looking at the Services API (because I'm interested in building a replacement calendar app). I discovered the following text at the top of the calendar services API documentation:
Note: To prevent unauthorized use of
private user data, this API provides
access only to records created by your
application; that is, you cannot
access records owned by another
application.
What is the point of even having an API if you can't access data created by other applications? At that point there would be no reason for me to use their API rather than building the data storage myself. Am I missing something? Can any WebOS developers weigh in on this?
P.S. If they named their os "WebOS" you would think they'd know something about sane URLs. Check out that ridiculous calendar api doc url!!
The reason for the limited access is because of security, but not just that. Some services have agreements that limit how their data can be used. For example, having an API that would let a random webOS app access your Facebook calendar data would be working around the FaceBook terms of service that control how that data can be used. The same applies to LinkedIn, Google Calendar, and any other service from which the system is pulling information.
If you just need to post an occasional event, there's a better API to use that lets you cross-launch the calendar app with data that the user can accept into their own calendar. That way, you don't create your own bucket, but the user has to manually accept the event.
The reason to use the calendar APIs is to expose your own data to the user of the device. FlightView, for example, uses it to publish a calendar to the user of upcoming flights that he or she is interested in, and if those get rescheduled, it can automatically change them. The Fandango app uses this to push movie times for theaters the user likes into their calendar view. There's lots of possibilities.
Related
I'd like to manage the playlists on my account automatically with a program I'm going to write. To this end, I took a look at the youtube API. However, it seems to me that the only sensible way to do that is to have a Google G Suite account in order to get access to the OAuth 2.0 API. At the same time, it confuses me that I need to pay a monthly fee just to be able to manage my own playlists. Am I missing something or is this indeed the only way?
You actually don't have to pay anything for normal operations (e.g. if you're able to function within the boundaries of the default quota allocated to your app). To manage (ie. list/create/modify/delete) your channel's playlists you'll have to use the following API endpoints:
Playlists.list, Playlists.insert, Playlists.update and Playlists.delete;
PlaylistItems.list, PlaylistItems.insert, PlaylistItems.update and PlaylistItems.delete.
For read-only operations on public data it suffices to have an application key.
For write operations you'll have to familiarize yourself with OAuth 2.0 authorization in the context of this API. See a brief top level description given by one of my recent answers. Then you'll have to go through the official docs referred to therein.
I'm trying to solve a problem of preventing double bookings using the Google Calendar Api (v3). I'm using Google resources in a GSuite environment. The bookings are made from a centralized platform on behalf of multiple users and are applied to multiple rooms (resources). The responsible application authenticates using a Service Account. The resource calendars are all configured to only accept invitations that do not conflict.
So far I found out that there are at least two ways to book a resource:
Create an event in the resource calendar
Create an event in a personal calendar en add the resource as attendee
I found out that in the first senario, events can be added to the resource calendar, even if they cause a conflict. There is no failure in the api response, the event is just added.
I tested the second scenario with my personal calendar and found out that the room needs to respond to the event invitation. Apparently that process may take several minutes before the room responds.
I'm building an api that should respond as fast as possible, but I want it to only create an event if it doesn't conflict. Of course I can use the free/busy information to reduce the chance of conclicts, but I would like to eliminate that chance entirely.
Does anyone know if Google provides functionality for this problem out of the box?
Thanks in advance.
Google does not do any validation on the api. You send what you want inserted and they insert it. Its up to you to ensure that it does not conflict with anything already there.
May i suggest that you check before you insert it and then do a double check in a few minutes to ensure there is no conflicts if there is then delete it again.
Currently, I have been tasked to utilize the Google People API to ask for a user's basic Google information along with their public phone numbers. So far the results have been positive.
The solution my team and I have incorporated the Google People API integration in has the capacity to be utilized across thousands of domains. As a result, my question is simply, How can my team members and I ensure that any our clients that utilize our solution with their own particular domain get our new functionality built with the Google People API?
Keep in mind, our clients have the flexibility to have http/https and any subdomain on their site. Entering each domain possibility for our client base one by one would not be an easy task. I'm seriously hoping there is a solution around the single, explicit origin entries.
Thank you for your time and help.
Warning:
You must remember that if this is source code you are giving your clients that you are not allowed to release your client id and client secret. This includes plugins and scripts.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
So if your clients could view the code of your application and see your client id and secret you should not be giving it to them.
Read more about this issue Can I really not ship open source with Client ID?
Recommendation:
The best solution for you will be to instruct your users now to create there own project on Google Developer Console and create their own JS origins.
You may just have to provide your own wrapper around the target API where you authorize the client request yourself and then do the request from Google using your own credentials.
With a simple java program, I send GET requests using YouTube Data API specifically videos.list, in order to get the public metadata of a video and store it as .json files.
For my universities research, we have to do this with all available YouTube video IDs provided in the Youtube-8M Database.
Therefore, I would like to know if there is a way to extend the available quota for requests (I already know about the billing option, but I am a student and my university is small).
I have read the YouTube API terms, which states that only one project per client may be used to send such requests with the necessary API Key.
If I understand it correctly, even my simple java code is such a client.
In some other Stack Overflow questions about extending ones daily quota with API Keys, some suggested creating multiple accounts or projects.
Is this a legal option or not? Or is there another possibility to get a higher quota for simple requests used in research like I do right now?
If you go to the Google Developer console where you enabled the YouTube API. the second tab is called quota
Click the pencil next to which ever quota it is that you are blowing out. A new window will pop up with a link called apply for higher quota.
Fill out the form to apply. To my knowledge you do not have to pay for additional YouTube quota but it can take time to get approved. Make sure you comply with everything on the form.
I have never heard of the one project per client term. Technically you can run your application using different API Keys it should work fine. Technically there is nothing wrong with creating additional projects on Google Developer console. You don't need to go as far as creating another Google account.
I would like to implement a Google Calendar API using FullCalendar Javascript.
Before any start of coding I have some problem to understand what is the main purpose of the Google Calendar API.
As you know there is some Auth process before creation and enabling API.
That means that I, as owner or developer want to use Google Calendar API so I get client/secret/keys strings and it is OK.
I can create an app where I can “promote” my Google Account Calendar being public and then I can show all events from that calendar (dentist booking etc).
Also I am able to use Calendar in another way. For example: Within my App I can create one page where users can auth to their google accounts and see their events
are already created.
But, What if my logged users don't have a Google Accounts.
Google Calendar is strongly connected to already created google accounts? Is it possible to use Google Calendar strictly as an REST API?
I know that this may be a stupid questions but this is something that most of Google Calendar API beginners have problem with.
There are technically two ways of accessing a calendar on Google Calendar.
Your first option is where you are using Oauth2 to authenticate your users. They give you access to their google calendar and you can then insert events directly into their calendar. You can also see the events that they currently have. This as you said wont work if the user in question does not have a google account.
Your second option is to use something called a service account. Think of a service account as a dummy user. It has its own Google calendar account minus the web view. You could potentially us that to store events in a global calendar application calendar. Then when you want to add a user to an event you invite them you can set notification no they should receive an email and they will them be able to add the event to their own personal calendar. For you this may work out better because it does not require you to have access to the Users google calendar the only draw back will be there is no way for you to see if said user has any events going on at that time since you don't have access to their account to check.
I have given you a couple of links to some tutorials that I have write a few years ago that explains the difference between oauth2 and service accounts.
Google Calendars are tied to users, which means Google users. First of all, to access the API you need a GoogleAPIs developer key. This requires a Google account. Then you need Google accounts to use or test with the API.
The Google Calendar is tied to a user account as described at https://developers.google.com/google-apps/calendar/concepts/. One thing to notice is that "event" is an atomic unit in the API and a calendar is a set of events. In other words, a calendar in the Calendar API isn't a timespan like we think of "this year's calendar", it's a set of event objects. Within the app you describe, if the users don't have google accounts then they don't have associated calendars. You would have to tie these users to some kind of public or shared calendar. It's unclear if using the Calendar API solely as a REST API as you describe (without actual or "verified" user accounts) is in accordance with the Terms & Conditions. That aside, in theory it may be possible to use a service like that as a REST API to suit your needs. Maybe you can try inverting the problem so an event becomes the user with a primary calendar. Now the location of the event can be treated as the API-event. Other (normal Google) users can "attend" the location, at the given time, created by this event (=user). You could also apply the same approach to invert the problem by location. Location becomes the user, event becomes the API-event, and attendees are normal users. The latter approach is used commonly in businesses to book resources like rooms, equipment, etc.