This question maybe a better fit on The Business of Software forum but despite my post on there, I'm still unable to determine the following: Can I use the Google API to build commercial software? If not how can the people behind Byline charge for their app?
Update: I'm specifically interested in Google's Picasa & Reader APIs
From the Google Terms of Service:
5.3 You agree not to access (or attempt to access) any of the Services by any means other than through the interface that is provided by Google, unless you have been specifically allowed to do so in a separate agreement with Google. You specifically agree not to access (or attempt to access) any of the Services through any automated means (including use of scripts or web crawlers) and shall ensure that you comply with the instructions set out in any robots.txt file present on the Services.
(emphasis added)
More specifically, when you say "the Google API", which of the many APIs Google exposes are you referring to? Each of them has different terms of use. Some can be used commercially, some can't.
Update:
from the terms for the Picasa Button and Uploader APIs
7.1 Subject to the Terms, you may develop, display and/or distribute your Button using the Services as part of a commercial or non-commercial enterprise, and you may develop your Button for use in accessing paid content or services. You may not charge a separate fee for use of any Button, unless you have entered into a separate signed agreement with Google. If you wish to sell or transfer your Button, you must obtain Google’s prior written permission.
from the terms for the Picasa Web Albums Data API
5.8 You may use the Picasa Web Albums API as part of a commercial or non-commercial enterprise, subject to these Terms. You may not however charge a separate fee for use of the Picasa Web Albums API unless you have entered into a separate signed agreement with Google.
As far as the Google Reader API is concerned, it still appears to be unreleased and so no specific terms are available.
To enter into a signed agreement with Google, you're probably best off contacting your local Google office and talking to one of their business development representatives there... Alternatively, you could try contacting the Business Proposals department from their contact page...
If you are talking about the Google Web Toolkit:
http://code.google.com/webtoolkit/doc/1.6/FAQ_GettingStarted.html#Can_I_use_GWT_to_develop_commercial/enterprise_applications?
The answer is Yes.
Which API do you want to use?
I think that Google Maps API has some limitations.
You should read the term of use carefully and make sure that it fits what you want to do.
Update: The Picassa API can be used in a commercial app but you can not charge the user for a separate fee. see 5.8 at http://code.google.com/intl/fr/apis/picasaweb/terms.html
Related
Some time ago I was browsing the web, when I found a service that allowed to access multiple API's using single, unified interface and single login.
I remember that I browsed the catalog of API's and check OCR services to see what features they offer.
I don't remember if it was a free service or paid one. I didn't bookmark it and now I can't find it. I have found only API's catalog on Programmable Web.
Is anyone knows the name of this service?
Well, after getting one vote down I decided to google more. No results. I reviewed bookmarks and... bingo!
It's called mashape.com and what I have had in mind was this catalogue.
Disclaimer: I have no connection to this service. I just liked the idea.
Edit:
I have just found API search:
{API}Search.
It does not allow to access mutiple API's using single credentials, but might be usefull for API's discovery.
This question is related to Stackoverflow Question -> Access licence number for UPS
When I registered for Developer APIs, I was given a 4-part credential: User ID, Password, Access Key, and Shipper Number. I used this and the CIE URL to get rates, print shipping labels, etc. So far so good. Everything works. I have been able to build and test desktop and web GUIs that use UPS API.
Now I understand that I need to implement UPS Registration API and Licensing API to apply for certification. I applied with UPS for this and received the API package. Again, so far so good. Now, I have two questions:
1- I understand that we can use the Registration API to authenticate existing UPS accounts for end users to access my application. We can also use it to allow the end user to create one or more new UPS accounts for use with the application. If Registration API takes care of this, what is the use of the Licensing API? UPS documentation isn't widely available and the documentation that comes with the API kit is very minimal.
2- My app will use the end users' UPS account numbers for shipping, but which Access Key should it use? Should it use the Access Key of each end user, or my Access Key for everyone? If the former, then should this end-user Access Key be obtained using the Licensing API? Is that the Licensign API's purpose?
In essence, I think both questions are the same but you can see how perplexed I am with respect to this requirement of implementing Registration and Licensing APIs!
Any insight from you experts would be REALLY great!
UPDATE:
Just wanted to add another question:
3- I am using UPS Web Services for all UPS functionality. The package that contains Licensing API and Registration API has a "Reference.cs" for the Registration API but not for Licensing API (only XSDs in that folder). Is the Licensing API not available as Web Service?
Questions on the licensing API should be referred to the folks at UPS Ready. This is not the proper forum.
I am newbie here and confused by few things
Some websites (twitter, foursquare, etc) provide API to third-party developer to call. are those APIs the web services that the sites provide?
Are those web sites themselves built on top of those public APIs/web services? theoretically is it possible?
Comparing the traditionally built website and the websites build on top of web service, pros and cons? are there any performance, scalability, etc differences?
Thanks in advance!
I'm sure somebody can give you a more exact answer but reading your question and applying my self-taught knowledge:
The simple technical definition of Web Services according to W3C:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
I like to think of web services as the interactive elements of a site that its customer base utilizes. For example, Twitter's web services include: tweeting, messages, hashtags, etc. Web services are what users get to DO or DATA passed back and forth.
A public web API provides means for developers to utilize the web services on their own site. For example, Twitter's API allows example.com site to utilize tweeting, messaging, hashtags, etc from within their own domain. An API is how developers get external access to web services to make apps using those services.
I have no idea about this question. I wouldn't do that. I would use the methods the public API exposes access to. But, I've never written my own API, let alone on the scale of Twitter or foursquare.
I hope this helps.
First of all, maybe you need some more info about what an API is: please take a look at the Wikipedia api page.
To answer to you questions (these are only general thoughts and not best practices):
An API, in this case, is a way that a developer uses to access a webservice, and it's not the service itself.
The websites you mention are not using their own APIs, as these APIs are meant for remote users (clients), and offer limited data sets, while the websites need maximum performance, access to the full database, and (almost) always use server-side code. The websites you mentioned, probably use other, server-side, high-performance APIs.
See the previous point: although it depends highly on which APIs you use, what you call "traditionally built websites" (that is, web applications using server-side APIs) can afford higher performance than websites totally built on top of remote APIs, because they do not depend on the bottleneck of the network connection (because, again usually, the web server and the database server either run on the same machine, or communicate faster than the client's browser and the server).
The reason that would make most people choose to develop a webapp the traditional way is that free APIs provide limited functionality (e.g. Google custom Search, limited to 100 reults).
After using the ebay API recently, I was expecting it to be as simple to request info from Amazon, but it seems not...
There does not seem to be a good webpage which explains the basics. For starters, what is the service called? The old name has been dropped I think, and the acronym AWS used everywhere (but isn't that an umbrella term which includes their cloud computing and 20 other services too?).
There is a lack of clear information about the new 'signature' process. Gathering together snippets of detail from various pages I've stumbled upon, it seems that prior to August 2009 you just needed a developer account with Amazon to make requests and get XML back. Now you have to use some fancy encryption process to create an extra number in your querystring. Does this mean Amazon data is completely out of reach for the programmer who just wants a quick and simple solution?
There seems to be a tiny bit of information on RSS feeds, and you can get a feed of items that have been 'tagged' easily, but I can't tell if there is a way to search for titles using RSS too. Some websites seem to suggest this, but I think they are out of date now?
If anyone can give a short summary to the current state of play I'd be very grateful. All I want to do is go from a book title in my database, and use Classic ASP to get a set of products that match from Amazon, listing cover images and prices.
Amazon 'widgets' can display keyword search results on my pages, but I have less control over these, and they are shown to the user only - my code can't look inside them.
Your post contains several questions, so I'll try to answer them one at a time:
The API you're interested in is the Product Advertising API (PA). It allows you programmatic access to search and retrieve product information from Amazon's catalog. If you're having trouble finding information on the API, that's because the web service has undergone two name changes in recent history: it was also known as ECS and AAWS.
The signature process you're referring to is the same HMAC signature that all of the other AWS services use for authentication. All that's required to sign your requests to the Product Advertising API is a function to compute a SHA-1 hash and and AWS developer key. For more information, see the section of the developer documentation on signing requests.
As far as I know, there is no support for retrieving RSS feeds of products or tags through PA. If anyone has information suggesting otherwise, please correct me.
Either the REST or SOAP APIs should make your use case very straight forward. Amazon provides a fairly basic "getting started" guide available here. As well, you can view the complete API developer documentation here.
Although the documentation is a little hard to find (likely due to all the name changes), the PA API is very well documented and rather elegant. With a modicum of elbow grease and some previous experience in calling out to web services, you shouldn't have any trouble getting the information you need from the API.
I agree that Amazon appears to be intentionally obfuscating even how to find the API documentation, as well as use it. I'm just speculating though.
Renaming the services from "ECS" to "Product Advertising API" was probably also not the best move, it essentially invalidated all that Google mojo they had built up over time.
It took me quite a while to 'discover' this updated link for the Product Advertising API. I don't remember being able to easily discover it through the typical 'Developer' link on the Amazon webpage. This documentation appears to valid and what I've worked from recently.
The change to authentication procedures also seems to add further complexity, but I'm sure they have a reason for it.
I use SOAP via C# to communicate with Amazon Product API.
With the REST API you have to encrypt
the whole URL in a fairly specific
way. The params have to be sorted,
etc. There is just more to do. With
the SOAP API, you just encrypt the
operation+timestamp, and thats it.
Adam O'Neil's post here, How to get album, dvd, and blueray cover art from Amazon, walks through the SOAP with C# method. Its not the original sample I pulled down, and contrary to his comment, it was not an official Amazon sample I stumbled on, though the code looks identical. However, Adam does a good job at presenting all the necessary steps. I wish I could credit the original author.
I wrote a blog post on this subject, after spending hours wading through Amazon's obscure documentation. Maybe useful as another view on the process.
I found a good alternative for requesting amazon product information here: http://api-doc.axesso.de/
Its an free rest api which return alle relevant information related to the requested product.
Some links i found:
Forum thread for amazon tutorial request
Amazon Web Services
Some sort of script for using the amazon eCommerce API
another tutorial for amazon web-store-y stuff
Amazon and ebay e-commerce API tutorials
Straight from the horse's moutyh: Summary of Product Advertising API Operations which has the following categories:
Find Items
Find Out More About Specific Items
Shopping Cart
Customer Content
Seller Information
Other Operations
Since the time when the question was asked in 2009 the changes have, unsurprisingly, continued and some of the answers and links provided are now superseded or deadlinks.
As of February 2022, Amazon now provide the Product Advertising API Scratchpad for developers to try out API requests so they can get up and running in minutes:
Scratchpad is a tool to help Amazon Associates send basic requests to
the Product Advertising API. Follow the steps below and you can have a
working request with sample code in minutes.
The linked page also has onward links to pages where you may
sign up for the Associate program and Product Advertising API and access the complete API documentation.
As mentioned by #Reg Edit in his recent answer, Amazon now provides a scratchpad for their Product Advertising API, which in-fact does have a "SearchItems" endpoint which presumably returns products for a search query similar to the one a shopper would enter into Amazon's search bar while shopping.
Here's a link explaining on how to get access to Amazon's Product Advertising API. This would be helpful for anyone looking to display Amazon product's on their application programmatically.
In order to get access to Amazon's Product Advertising API, you must meet the following 3 requirements:
Have completed 3 sales in the last 180 days
Have an approved associates account
Comply with this agreement
Now if you don't meet the above requirements, the only other option Amazon gives you is to use their SiteStripe widget, which is a tool to help associates build links manually.
If you do not meet the requirements listed above and would still like to get Amazon product data for your app or website programmatically, you may use web scraping to achieve the same. Since the data is public, no one can legally stop you from scraping it. Depending on how experienced you are with programming, you could either build a scraper yourself or use a service that enables you to do so.
I have built one such service myself—it is called Amazon Product Search API and it allows users to grab search results from Amazon including product title, thumbnail, URL, etc. for any search query a user would make while shopping on Amazon. It supports all the major countries Amazon operates in.
Using this service does not require you to be an Amazon associate. Users may scrape up to 10k search results for free.
Several web service APIs have you sign up for an API key. For example, UPS Web services requires a key, which is included in calls to their service -- In addition to the username and password.
What is this key used for by the provider? Perhaps UPS is the only one to require both API key and username/password?
One idea is that they use it to limit or measure API usage, but it seems to me that a setting in the users profile could easily do the same thing -- especially since you generally have to get an account w/ username and password to get the API in the first place.
There are two predominant use cases. The first is to measure, track and restrict API usage. If someone is building a service that allows third parties to access it, the service provider may want to control (or at least know) who has access so that they can try and prevent things like denial of service attacks. On the measure and track side, interesting information can be obtained such as knowing which applications are popular for accessing the service or which features people use the most.
The other use case is related to security and authentication. It is unwise for a service provider to have third party applications and services require users to give up their username and password for the primary service. This is a huge exposure. That is why many services are standardizing on protocols such as OAuth, which provides delegated access via authorization to a user's data. While not foolproof, it is definitely preferable to distributing user credentials to unknown, and untrusted, parties.
Most of the time it is to monitor how developers are using the web-api. If they somehow disagree with your usage of the api it provides a means for them to shut it/you down without hurting the other users. And the statistics per user/app are always valuable.
I've used the flickr api - in that situation the key is yours, but the login data might be those of people using your app, so the api key is the only way to differentiate between the apps.
Usually it used to get stats on how much application performing queries to API.
I think asking username/password with API key is ambigious in some cases, but it is a way how it is implemented - so we can't do something with it.
They ask for API key because you could have more than one API under same account - in case you have more than one site which are use same API.
They could use it to signify which version of the API you are trying to use. Perhaps in Version 1.0, there is a method that takes a POST on www.UPS.com/search and there is another one in version 2.0 at the same address, but takes a different parameter set, or even returns data in a different format/style. Your program was built on V1.0 and expects a certain API contract. They want to be able to create V2.0 without interfering with their customer's products.
That's just a guess, but it sounds good to me.
I think Gracenote does a similar thing for cddb. I forget the details, but I remember something about some token.
(They have/had really draconian rules about using their service too.)
Simon reminded me what the gracenote thing was. Gracenote and Fedex and other webservices have lots of developers writing apps for the software. So the developers get a token to put into their apps, but the end users have their own user name and password. It lets the services keep an eye on abusing programs, etc. That is probably te primary reason. (like a browser or a webbot informing the webserver who/what it is)
Originally, Blogger required you to apply for an API key (a la Google Maps) and used it to restrict access to the API. As Blogger evolved into Metaweblog, the requirement for the API became less important, and Blogger no longer requires you to apply for a key. As noted by others, it can still be used for tracking purposes.
In our situation, our clients want it for:
Tracking/analytics - figuring out who's doing what and building what products. Because a number of users are desktop apps, just looking at referrers isn't always enough.
Permissions - which resources should a user have access to? How can a user build apps that have access to specified resources?
Licensing/legal - enforcing that users have read and accepted ToU/licensing information.
Security - passing around usernames/passwords is a really bad idea.