Hello I am currently writing a native SoundCloud application for OSX. In order to write that application I need an object oriented wrapper that gives me the SoundCloud data in form of objects. Now I have several questions regarding the api:
Users are allowed to forbid access to their songs via third party applications, I guess this a protection to avoid that the songs are downloaded, are there made any exceptions for third party developers?
SoundCloud itself is not only using the public api but also some other private api's, am I allowed to use them if I arrange it with you(with the api-team)? (The reason why I am asking that is that the public api is not reflecting all data for example the me/activities endpoint does not reflect the user that reposted a song.)
If no, will you allow it in the future?
With private api's I mean endpoints that are hosted under the url api-v2.soundcloud.com
Thank you in advance for an answer.
Artists can forbid access to tracks for third party apps which was the reason why I didn't get any tracks for the playlist.
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 am asking this question after extensively reading Google's recommended approach, but I do have a problem with all these approaches, let me explain the situation.
I use combination of geolocation and geocoding API to know the approximate state location and then display relevant content. The geolocation API needs to be called obviously from the browser to get appropriate geolocation of the user. Google provides HTTP Referrer based restriction for this API. I know someone can easily spoof the referrer and make calls with the same API key. I do not see a huge advantage even though Google recommends this.
On the other hand Google does not allow HTTP Referrer for geocoding API, but it does allow that for the MAPS JavaScript API. But again if you are not using Google maps then using that API is violation of Google's terms. Now google recommends to move the code that uses geocoding web services API to be on the back-end so that your key will be protected. But since ultimately I need to deliver the result to a front-end web application that is publicly accessible and I can only make a browser based Ajax call to first get the geolocation to feed to geocoding, I ultimately need to make an Ajax call to get my geocoding information. Then someone can easily just latch onto my end-point to piggy back on and call the geocoding API as much as they want. So for situations like this I want to know what is the ideal and secured way to deal with. May be there are other APIs that might be an ideal situation for this.
In my case, I am not doing any maps so it's all purely server-side to get latitudes, longitudes and driving distance between two points. This today from Google support which might help and if you're using maps, then the links may provide further insight.
Regarding API restrictions, please note that HTTP referrers will not
work on Geocoding API since HTTP referrers can only be used for client
side services. In other words, Geocoding is a web service API and
should only be used on server-side implementation. IP address
restrictions should be used for web service APIs. However, if you are
using the Geocoding API in a website, IP address restriction would not
work. Please check the suitable restrictions for each API in the
following link:
https://developers.google.com/maps/api-key-best-practices#api_key_table
To make this work, you should create a separate key and use the new
one in your Geocoding API request URL. You may add a restriction to
this key by using an "API restriction", and restrict it to Geocoding
API only. If you don't want to create another key, you may keep using
your current one but make sure to change your implementation and use
the client side Geocoding service from the Maps JavaScript API. In
that case, please refer to this documentation:
https://developers.google.com/maps/documentation/javascript/geocoding
Another suggestion would be to get a static IP address from your ISP,
especially if you are planning to use it on a public website. For
development purposes, a sound solution would be to get three separate
keys: one for the staging and tests, another for server-side requests
and a third one for client-side requests. That way, you are making
sure your API key is protected.
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.
Can the full functionality of the Facebook Graph API be used with HTTP Requests, rather than using any of the SDK's? I've been able to use a GET requests to return public data; I've been able to use a POST request to make a post with an access token retrieved from Facebooks Graph API Explorer, but I'm not sure if Login, getting Access Tokens and determining whether a user has given permissions, is possible without using one of the SDK's? I could spend the next 2 days using trial and error, and reading docs to try to find out, but I'd hate to waste a couple days going down a road to nowhere if someone can just give me the answer now.
Yes, absolutely you can create application for Facebook without using any SDK..
SDK is just a software development kit (SDK or "devkit") it's typically a set of software development tools that allows for the creation of applications for a certain software package,
Facebook SDK made your work much easier because they give you ready made functions to call Facebook API
like PHP sdk ,C# sdk.. etc
If you want to create application without using it .. then you have to request Facebook Graph API directly ..
For e.g you need to get page information using JS SDK ..you need to pass only name/id of the page
in JS SDK
FB.api('/cocacola', function(response) {
console.log(response);
});
but if you want to go without SDK, then you need to call http://graph.facebook.com/cocacola
now you need to parse JSON then retrieve data based on the language you're working on
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.