I'm building a suite of tools that integrate with Asana. These tools comprise a web browser extension and a web app (or Chrome packaged app). Do the browser extension and web app share the same API call quota?
Right now, API rate limits are enforced per-user. Until we released OAuth support, there was no way to distinguish between different apps (since users were always authorized by the same API key). In future, each app will get its own rate limit quota (per user). If you intend to make them separate apps (and have users authorize them separately) they would then get separate quotas - but if you're either using an API key for both, or sharing one OAuth app, they'll end up sharing their quota, too, even if we roll out the change I mentioned earlier.
Related
I manage several projects, each project includes several API Clients (Android App, iOS App, PWA and backend server).
Glossary from yt API terms:
"API Client" means a website or software application (including a mobile application) developed by you that accesses or uses the YouTube API Services.
"API Project" means the project created in the Google Developer Console that is required for API Client(s) to access and use the YouTube API Services.
Following yt API terms I must create exactly one (1) API Project for that API Client. Those API Credentials are intended to be used exclusively by the associated API Client, which means that you must not use that one (1) API Project for multiple API Clients.. Then I understand that I should create one API Project for Android App, one more for iOS App, etc.
But I've recently received following email from Google:
We have recently detected your Google Cloud / APIs Projects have been circumventing our quota restrictions via multiple projects acting as one and appears to be violating YouTube API Terms of Service (III.D.1.c).
To fix the problem please delete all projects using YouTube API usage except for one project you wish to keep active
Then if I delete API Projects and keep a single one for all my API Clients, that means I should use one API Project for multiple API Clients, that is forbidden by terms.
What's the best way to follow ?
I am integrating Onenote with my application. I am using MS Graph API's for getting data from Onenote. To consume the api's I am generating the token as mentioned at link get auth tokens.
I am registering my application at MS application registration portal. Do we need to purchase any kind of paid license to use services provided by MS graph API's.
The app registration process seems simple and doesn't differentiate between applications that can be used in production/test environment.
The app registration process seems simple and doesn't differentiate
between applications that can be used in production/test environment.
Apps registered in the app registration portal can be used for production or test environments. There isn't any switch that needs to be set when you're ready to ship. Congrats on shipping your app to production!
Do we need to purchase any kind of paid license to use services
provided by MS graph API's.
We don't charge for access to the API. Some of the services exposed in Graph via APIs require licenses like Intune. It sounds like you're using OneNote so as long as users of your app are already using OneNote you're fine to access their notes via our API. Just be sure not to DDOS us :)
If you can share, our community would love to hear about your app!
I use the Twitter SDK for iOS (and Android,too). My iOS app pulls some tweets from the Twitter API via network request.
In the documentation (https://dev.twitter.com/rest/public/rate-limiting and https://dev.twitter.com/rest/public/rate-limits) Twitter describes some rate limits for requests and differs them "Per User or Per Application".
My iOS app pulls for example information from the endpoint https://dev.twitter.com/rest/reference/get/search/tweets with "guest authentication" (means: usage "Per Application" - not "Per User") to build a Twitter social wall.
What I don´t understand: What does Twitter mean in this case with rate limit for an Application? Does this means single instance of my iOS app on a device has it´s own rate limit for this request or does all my total instances of all iOS apps share this rate limit together (because the authentication uses the same fabric-app keys on all devices)?
I´m confused ... can somebody explain this to me, please?
Rate limits for application authentication are shared by all apps connecting with the same application credentials. Basically, rate limits are applied per access token, as described here. You can use the rate_limit_status endpoint to find out the remaining number of requests your app can make in the current 15-minute window.
I'm new to the OAuth Authentication process so be gentle:
Goal: To create an embedded application on a device that will integrate with Google Drive, Dropbox, One Drive, Box to retrieve & store documents. This can be easily accomplished with OAuth2 authenticaiton.
Problem: The devices have limited input capabilities (and no browser) that prohibit users from being directly redirected, for them to input username/pass on the device.
Research: I've noticed looking through the documentation for these APIs that Google provides something called OAuth2 For Devices which allows the device to request a "User Code" when they first attempt to use the application on the device. The user can then go to a computer, navigate to a specific URL, and input that code to authorize the device to access their account. This circumvents to need for user input, or a browser at all, on the physical device.
Question: Do Dropbox, Box, OneDrive, or any others allow for this type of functionality, or anything comparable? As far as I can tell Google is the only one supporting this type of workflow.
Recently i've researched the same question and i've found out that while Google Drive Api supports OAuth2 flow for limited devices, it supports a very limited set of scopes. It means that Drive api for limited devices can offer only application data synchronization (files uploaded by app), because it won't find any files created by the user (outside of application, i.e. from web) even in a dedicated application folder. (assuming that user understands that application owns that folder and everything placed there ideally should be accessible by that)
By 2022, i've found the most promising api is from Koofr which doesn't have such limitation for devices and bundles multiple cloud services into one package.
Their documentation doesn't mention support for limited devices, yet it's fully working and can be found in their online HTTP api test suite.
We currently have a MVC5 web application that has recently gone live. Much of the business logic is contained within GET and POST controller methods in C# files. A native iOS app is planned for the project and the concern was expressed that we must ensure that the business logic is the same for the web app and the mobile app. I'm asking for anyone with experienced with Azure Mobile Services to elaborate on how we can easily ensure consistency between the web app and the mobile in terms of backend business logic. I see two options as of right now: 1. Create an API project and ensure both the web app and the mobile app call the same endpoints 2. Integrate Azure Mobile Services and ensure that the business logic matches the web app at all times. I'm just looking for guidance.
Thanks
If you are starting work now, I would start work with Azure Mobile Apps rather than Azure Mobile Services. Azure Mobile Apps can provide a web app and a mobile-friendly API for you.
Azure Mobile Apps provides three distinct things on top of Azure Web Apps. The first is a mobile-friendly data-sync capability. This is a RESTful interface that provides access to data from a backend resource. You can use it directly as a REST endpoint - great for your websites, but it is also an OData source. There are clients available for iOS (Objective-C/Swift), Xamarin (C#/.NET) and more coming that use this to provide a sync capability. The addition of a SQLite store provides an offline sync capability that your mobile app can utilize for performance and network efficiency.
The second is authentication that works with the mobile data-sync capability. This can be used across your web and mobile apps and links into enterprise authentication systems (via Azure AD), Facebook, Twitter, Google+ and Microsoft Account. One of the more interesting things you can do is provide personalized results - a user can only access their own records via data-sync. Mobile authentication is different and the SDKs provided in addition will provide that functionality for you.
Finally, there is a pass-through for Notification Hubs - a powerful push notifications system that provides access to APNS (for iOS devices), GCM (for Android devices) and WNS (for Windows-based devices) as well as push capabilities to Chrome and Safari web apps, Baidu and Kindle.
Nothing stops you from doing all this from a standard MVC5 ApiController, but the wrapping of the client-side SDK plus the additional functionality of the table controller reduces the complexity of the code you have to write.