Reading through the Flickr API documentation it keeps stating I require an API key to use their REST protocols. I am only building a photo viewer, gathering information available from Flickr's public photo feed (For instance, I am not planning on writing an upload script, where a API key would be required). Is there any added functionality I can get from getting a Key?
Update I answered the question below
To use the Flickr API you need to have an application key. We use this to track API usage.
Currently, commercial use of the API is allowed only with prior permission. Requests for API keys intended for commercial use are reviewed by staff. If your project is personal, artistic, free or otherwise non-commercial please don't request a commercial key. If your project is commercial, please provide sufficient detail to help us decide. Thanks!
http://www.flickr.com/services/api/misc.api_keys.html
We set up an account and got an API key. The answer to the question is, yes there is advanced functionality with an API key when creating something like a simple photo viewer. The flickr.photos.search command has many more features for reciving an rss feed of images than the Public photo feed, such as only retrieving new photos since the last feed request (via the min_upload_date attribute) or searching for "safe photos" only.
If you have a key, they can monitor your usage and make sure that everything is copacetic -- you are below request limit, etc. They can separate their stats on regular vs API usage. If they are having response time issues, they can make response a bit slower to API users in order to keep the main website responding quickly, etc.
Those are the benefits to them.
The benefits to you? If you just write a scraper, and it does something they don't like like hitting them too often, they'll block you unceremoniously for breaking their ToS.
If you only want to hit the thing a couple of times, you can get away without the Key. If you are writing a service that will hit their feed thousands of times, you want to give them the courtesy of following their rules.
Plus like Dave Webb said, the API is nicer. But that's in the eye of the beholder.
The Flickr API is very nice and easy to use and will be much easier than scraping the feed yourself.
Getting a key takes about 2 minutes - you fill in a form on the website and then email it to you.
Well, they say you need a key - you need a key, then :-) Exposing an API means you can pull data off the site way easier, it is understandable they want this under control. It is pretty much the same as with other API enabled sites.
Related
I am working on a desktop application using GCP Speech-to-Text API to perform streaming recognition. I'm using Python 3 and Google client libraries, google.cloud.speech. I've started off the transcribe streaming infnite Python sample and built around those concepts, and everything works nicely. I'm now trying to get to the end user access question, as I'm currently using a service account file for development purposes, which I'm obviously not willing to distribute to all users.
Basically, how do I give access to my end users to the Speech-to-Text service for streaming recognition in the least intrusive way possible? I have no need for accessing storage or the like, as I don't access buckets contents and stream all audio directly. I actually don't need any user information, I only need GCP to process the STT requests and send me the responses.
I see 2 solutions that should work on paper, out of the three the documentation mentions (I leave out the service account file ones):
API key
OAuth2
API key
API keys sound like my dream option: it's simple, doesn't require user interaction past initial setup, I can manage such keys in GCP's console, and it should be able to grant access to what I need (as I effectively don't need any user info, an account is mostly irrelevant).
However, how to use an API key using the Google Speech client library totally eludes me. I can see a PUB/SUB Go example, but I can't find any mapping to Python. I'm not even 100% sure it can work, as the Go documentation for the option seems to note it only works for JSON-over-HTTP, and I believe the client library for Speech-to-Text is using gRPC.
Yet, at least with a JSON non-streaming recognize request, I can use such an API key, and successfully did so manually using cURL on the command-line. So I still have a little bit of hope, in case the gRPC restriction either isn't true or doesn't concern my use case.
This part's question would summarize as: "how do I specify an API key using the Python SpeechClient?".
OAuth2
This sounds like my second-best option, as it uselessly asks the user for authentication while I don't actually need any personal data. Yet, I still have serious issues I'm struggling to overcome:
How do I reliably store info that prevent me from having to re-ask the user for authorization every single time the app runs? google_auth_oauthlib's InstalledAppFlow doesn't seem to provide such feature, so I'm rolling my own based on google.oauth2.credentials.Credentials.from_authorized_user_file() after having saved them with the to_json() the first time I obtained them with InstalledAppFlow. I'm however confident this will not last, and I'm really not sure how to check whether the credentials are still good before I fail to use an API with them (e.g. I can't seem to be able to rely on Credentials.valid before they actually get used).
There seem to be no specific Speech-to-Text scopes, and the required one is way broader than what I need, leading to an overly complex and frightening authorization request. And no, without this scope I cannot access the Speech-to-Text API, I tried :)
Summary
To summarize: what is my best and least-intrusive option to provide credentials to be able to use GCP Speech-to-Text in my desktop application?
[React/NodeJS] I'm having a huge struggle in finding the appropriate documentation on this topic -- I am looking to implement PayPal on my website, with the constraint being that the customer is charged after our offline service is completed (has variable costs, but there is something of a solution in mind such that if I can 'authorize' an amount equal to our maximum cost that we will be a-okay). My initial research indicated to me that PayPal Orders fulfill this desire, to at least an effective extent, ie. the order is placed and funds are not placed on hold until we authorize the charge, ideally after the offline service is completed (source: https://developer.paypal.com/docs/integration/direct/payments/orders/#order-response). Upon further inspection, I have discovered that the integration path using PayPal smart buttons is being heavily advocated in implementation docs and appear to be compatible with the orders API (source: https://developer.paypal.com/docs/checkout/).
I began working to implement the software, following the smart buttons implementation linked just prior, and followed the instruction to use server side api calls to process the payment (source: https://developer.paypal.com/docs/checkout/integrate/ and https://developer.paypal.com/docs/checkout/reference/server-integration/set-up-transaction/). Continuing forward, I pursued order creation explicitly using the orders API (mistake perhaps?) and used the docs for the v2 orders api and the docs for the nodeJs sdk package referenced in the paypal docs (paypal/checkout-server-sdk using the github docs). I set up the integration and the sandbox accounts showed that charges were being placed however, and this was contradictory to my desire to not place charges on hold until an authorization is completed. The status returned on the backend is kept at "created", so I was initially optimistic, but the charge placement was unfortunate.
I am struggling to find the next step. As the checkout-server-sdk is utilizing both payments/v2 and orders/v2 (source: https://www.npmjs.com/package/#paypal/checkout-server-sdk), I am lead to believe I can utilize those API endpoints as well, but can't find explicit functions that call the payments api in question in the checkout-server-sdk, which I believe I would need to change order intent in order to create an order (source: https://developer.paypal.com/docs/integration/direct/payments/orders/), but also noticed these docs (linked as active directly from the docs page for paypal I believe -- https://developer.paypal.com/docs/ ) post to payments/v1 (source: https://developer.paypal.com/docs/integration/direct/payments/orders/) which has been deprecated. Long story short, I am now lost and would thoroughly appreciate some guidance on where I walked astray, what docs to refer to, if this implementation is still supported, and potentially what the next step is. If I used incorrect verbiage or have some noticeable jump in logic that was to my detriment, I would love to know as I am fairly new to developer work as a whole. Thank you in advance!
Your use-case of not placing a temporary hold up front requires intent:order, and only the v1/orders API has this available. The v2/* APIs do not.
An intent:authorize hold typically clears from a card after about ~3 days (even though it is capturable up til day 29), so I would recommend using the v2 APIs if that's workable. But if it's important to not do that, then v1/orders can be used. The API is not going to disappear, people are using it. Even-yet-older Classic APIs with similar PAYMENTACTION=ORDER functionality are still in heavy use, after all.
I am writing a desktop app using PyQt5 which uses the Wordnik API to get word definitions. I do not have server-side access, nor do I wish to invest in acquiring it. Is there any way I can reliably hide my key so I can share my program on GitHub?
At the very least you could store your API key in a separate source file (which you would exclude from the repository via .gitignore) and check for exceptions while importing that file (see this), alerting to provide own API key if that fails.
Storing the API key in a non-source configuration file is another option, but then your worries are in storing that file in a way that is not accessible to the end user of your application.
Unfortunately, no, our Wordnik terms of service don't allow for sharing keys where they are accessible by end-users. If your app is noncommercial you can share instructions for users to help them apply for and add their own Wordnik keys to their copy of the application (and this also helps you, in that your key won't hit our API limits based on your users).
If this is a commercial application, please get in touch with us (apiteam#wordnik) with more details about your use case as we are looking into how to make this easier. As a small nonprofit with limited engineering resources we can't promise a quick solution but since our mission is to find & share every English word we're always interested in learning more about how folks are using our API. :)
Thanks for using Wordnik!
I usually send out emails with links to document downloads. Is there any chance of registering statistics on those using Google Analytics?
Javascript and Google Analytics doesn't work in HTML emails, so you can't measure the clicks on those directly.
If you use an email service provider, like Mailchimp or one of the many others, they will provide click-tracking at not additional cost, so you could consider that. Most ESPs will have a free or freemium plan you can try.
Otherwise, you can do the following:
Route all clicks through a script that counts the clicks. Pros: accurate count. Cons: custom development, re-inventing the wheel.
Direct all the clicks to a landing page that has Google Analytics implemented. Pros: easy implementation, no custom development. Cons: extra click will lead to some dropoff.
I would recommend an email service provider. Besides the click-tracking, it will give you much better deliverability, testing tools, and reporting options.
You could try using an intermediary page that sends off the GA Tracking Beacon before redirecting to the download. This could either be done using JavaScript that works in a similar way to outbound link tracking or using a meta-refresh. Either way you would want to put a message on the page stating that the download will start shortly and a redirect link in case something goes wrong.
I would like to create an app for a myBB forum. So the site on the forum will look nicer and much more cleaner on an iPhone or Android.
Is it possible without an API? It isn't my site ether.
everything is possible, it's just a matter of resources...
technically, you can write an app for everything on the web, but:
an API will tell you how you can do things with the site, without having to reverse engineer all pages/posts/..., and the format of every output resulting from post/get operations. reverse engineering may take a long time, and you will surely not come accross all possible results (error pages, bad authentication...);
an API is quite stable and is always updated with great care from the developpers so as not to break existing applications. without an API, there is no guarantees that your app will not break with the next release of the forum when it is upgraded;
a web API generally defines an output format which is easily parseable: many API outputs XML or JSON, which can be processed with standard libraries. without an API, the output format is plain HTML, which may be difficult to reorganize in order to show the results in a different format.
so, yes, you can definitely write an app for a myBB forum, but it may require a fair amount of work.
You can do, it's called screen scraping and is what was done before XML, the semantic web, SOAP, web services and then JSON apis tried to solve the problem better.
In screen scraping, you grab the site's HTML, parse it, get the data you want out of it, then do what you need with that data. It's more work, and breaks each time the site's layout changes, hence the history of improvements to it.
You mention the site in question is not yours. Many sites do not regard screen scraping as fair use, so check with the site's terms and conditions that you can legally create an app from the data posted there.
you can consider useing HTML5 ... do you think it doable for use app ?