I am building a Web application, and Web API. The Web application will do ajax call to the server and receive JSON results. The same will happen to the Web API.
I am planing to ask developers to use keys to access the Web API so that I can charge for their uses of it.
The problem is the Web API will be use by the Web application to get the content for the web pages. Is there a way to know if it is my Web application using the Web API or someone trying to highjack the API so that they don't have to pay for it?
I am using PHP on my server.
It's difficult to protect completely but there are techniques that help. ApiAxle (disclaimer: my company) gives you the option of using short lived keys. These will be impossible for a leecher to generate without knowing your secret key. Paired with rate limiting you're getting somewhat closer to where you want to be.
Not foolproof but a start.
When trying to secure something on the web, it might be useful to think about how you want to protect the information that you provide by the api before you try to find a technique for protecting the api.
An example:
Say that your api provides the current weather in London and your web application is an open web page that provides this information while also showing some web ads. You don't want someone else to use the api and show the Lonodn weather somewhere else without showing the web ad because that would ruin your sole income from this service.
You could limit access to the api by providing i.e. short time keys or another complicated protocol, but the problem here is that the information you provides, the London weather, is available to anyone on the web page anyway. If someone wants to "steal" your information and provide the London weather on a different web site they can just write a script that loads your web application, reads the information from the web page and display this in their own web application.
If a person is able to access the information, then he can also write a script that reads this information and display the information somewhere else.
Securing information is actually more about limiting who you want to give access and not so much about how they should get access. If you or your clients makes this information freely available on the net in one form or another, then you cannot (technically) prevent someone else from picking it up and redistribute it.
Related
I am looking to develop a cross platform mobile app involving real-estate. I have looked at Zillow's API and I think that will be one of the API's I utilize.
https://www.zillow.com/howto/api/APIOverview.htm
My question is if I were to utilize their API as well as those of some other real estate sites, would it make more sense for me to call those APIs directly from the mobile applications, or would it make more sense to have a proxy server, possibly with my own databases compiled from these sites, that the mobile application would call? I have only read the basic overview of the Zillow API, but it looks like it is limited to 1000 calls per day. I understand it is a fairly general questions. If there are any more details that would help to make a better answer, please let me know.
Also, if you know of any other free/cheap real-estate APIs, can you please provide them?
Thanks
Not exactly sure what your metrics are.
But generally speaking, it is a bad idea to hook your mobile app directly to third party API for the following reasons:
You do not control the API, if the third party changed their API your app won't work, the user would have to upgrade. But if you isolate the mobile app by connecting to your server you have more control and can have much longer life.
Caching/rate limits. You can get the data from the third party and store it (if you are allowed) then share the data with all your users
Multiple datasources: Usually you get the data from multiple datasources, so aggregating the data on your server then send the enhanced data model to the app is a lot easier than pulling data from different sources and compiling them on the app itself.
An application-programming interface (API) is a set of programming instructions and standards for accessing a Web-based software application. Could someone explain to me in case of Google maps or Youtube which is the API and which is the software application? Are both visible to us and how? I know there are tons of articles out there, however I cannot clarify the above. APIs are like the waiters that transfer data among different machines. Okay, which exactly is the Google maps API and how do we call/use it? And which is the Google maps software application which is accessed by the API? When we write for example http://maps.google.co.uk/ do we call the API? My query may seem silly but I cannot find a good answer for that.
An application-programming interface (API) is a set of programming
instructions and standards for accessing a Web-based software
application.
Firstly, an API is not just for web-based software. Even your computer's OS provides APIs for hardware and software installed in the box.
For your question, an API is a method (code instructions) to connect your application to the features of another system. Allowing your application to use thay system's features as provided via the API.
Could someone explain to me in case of Google maps or Youtube which is
the API and which is the software application?
In the case of Youtube... Let's say you are making some Android video player app that you also want to be able to playback Youtube videos within that app. The software application is your own Android player code and to access the Youtube data you would use Youtube's Android API.
An example of using the API is this module : YouTubePlayer which as you can see provide API commands like loadVideo(String videoId, int timeMillis). Where videoId is the Youtube ID and timeMillis is the desired start time within the video).
When we write for example http://maps.google.co.uk/ how do we call the
API?
That's not how you would call the API. You must first visit the documentation of the API to see how it's expected to call features within your own app.
Google Maps : https://developers.google.com/maps/documentation/
Let's assume now you're coding a Javascript app, you can see the commands here as a startng point. There is also an example page showing code & result.
Simple terms:
API = the waiter
Application Software = the chef
You order from the waiter. The waiter brings it to the chef. The chef prepares the food. The waiter then brings you your food. Then you figure out what to do with the food; eat it, take it home, throw it on the floor, let your dog eat it, give it the homeless, etc...
A website, app, etc... would send an API request (your order with the waiter) to Google Maps (the chef). If your API request is valid, Google Maps will send back an response (your cooked food with the waiter). Then the website or app takes the returned data and displays it in their custom way to you.
In the case of Google Maps, apps like Yelp and others use Google Maps' API to request specific data; routes, addresses, etc… and then they display it on their app.
To make an API request/call you have access to use the API, format it correctly, and figure out what to do when Google sends a response back : https://developers.google.com/maps/documentation/
API is a set of functions and procedures that allow the creation of applications which access the features or data of an operating system, application, or other service.
An API is like building block for your application. Multiple API's can exchange data without knowing the other's implementation. In a good design pattern , we should design API's for different independent tasks and then merge them.
Google Maps API
This is the google maps API which a developer can use to develop his own piece of software.
Whenever we use any software and it's different features, we might be using their API's without generally knowing of them.
A software application is always visible to us, but an API is visible only if the developer wants to expose it for community use.
EDIT
Using Google maps API
This link has the documentation and examples on how to use the google maps API using javascript.
Hope it helps!
When you use software, web applications included, you are in most cases using a wrapped API. Software developers took the time to take a raw back end API which executes commands on the system, and made these endpoints easy to use for a specific user in an intended universe of discourse, or domain. End users do not have direct access to everything the API has to offer all at once, so it is not "available" in the same sense that it is available to the developers, but it is available in another sense because they are using the API to execute commands on the system by virtue of the Application that was Programmed with that Interface existing and working.
The Google Maps API is used to integrate the power of Google Maps into almost any application. It provides facilities for customization and much more. When you use the Google Maps webapp, it is, to my knowledge, built using many components of the Google Maps API, as are the Google Maps apps for any other platform, such as Android. Does this mean you as a user are using the API? Only through the application; the application talks to the API for you.
“An application programming interface (API) is a set of routines, protocols, and tools for building software applications. An API expresses a software component in terms of its operations, inputs, outputs, and underlying types. An API defines functionalities that are independent of their respective implementations, which allows definitions and implementations to vary without compromising each other. A good API makes it easier to develop a program by providing all the building blocks.
APIs often come in the form of a library that includes specifications for routines, data structures, object classes, and variables. In other cases, notably SOAP and REST services, an API is simply a specification of remote calls exposed to the API consumers.
An API specification can take many forms, including an International Standard, such as POSIX, vendor documentation, such as the Microsoft Windows API, or the libraries of a programming language, e.g., the Standard Template Library in C++ or the Java APIs.
An API differs from an application binary interface (ABI) in that an API is source code-based while an ABI is a binary interface. For instance POSIX is an API, while the Linux Standard Base provides an ABI”.
To speak plainly, an API is the messenger that runs and delivers your request to the provider you’re requesting it from, and then delivers the response back to you.
To give you a familiar example, think of an API as a waiter in a restaurant.
Imagine you’re sitting at the table with a menu of choices to order from, and the kitchen is the provider who will fulfill your order.
What’s missing is the critical link to communicate your order to the kitchen and deliver your food back to your table.
That’s where the waiter (or API) comes in. ”AHEM”
The waiter takes your order, delivers it to the kitchen, and then delivers the food (or response) back to you. (Hopefully without letting your order crash if designed correctly)
Now that we’ve whetted your appetite, let’s apply this to a real API example. In keeping with our theme, let’s book a flight to a culinary capital – Paris.
You’re probably familiar with the process of searching for airline flights online. Just like at a restaurant, you have a menu of options to choose from ( a dropdown menu in this case). You choose a departure city and date, a return city and date, cabin class, and other variables (like meal or seating, baggage or pet requests)
In order to book your flight, you interact with the airline’s website to access the airline’s database to see if any seats are available on those dates, and what the cost might be based on certain variables.
But, what if you are not using the airline’s website, which has direct access to the information? What if you are using online travel service that aggregates information from many different airlines? Just like a human interacts with the airline’s website to get that information, an application interacts with the airline’s API.
The API is the interface that, like your helpful waiter, runs and and delivers the data from that online travel service to the airline’s systems over the Internet.
It also then takes the airline’s response to your request and delivers right back to the online travel service .
And through each step of the process it facilitates that interaction between the travel service and the airline’s systems - from seat selection to payment and booking.
So now you can see that it’s APIs that make it possible for us all to use travel sites. They interface with with airlines’ APIs to gather information in order to present options back to us
The same goes for all interactions between applications, data and devices - they all have API’s that allow computers to operate them, and that's what ultimately creates connectivity.
API’s provide a standard way of accessing any application, data or device whether it is shopping from your phone, or accessing cloud applications at work.
So, whenever you think of an API, just think of it as your waiter running back and forth between applications, databases and devices to deliver data and create the connectivity that puts the world at our fingertips. And whenever you think of creating an API,
--MuleSoft
I've googles about it, yet couldn't understand it properly.. Not sure if it's a library or intra-server communicator..
Can someone explain me in a high-level /low-level what is meant by an API.??
http://en.wikipedia.org/wiki/Application_programming_interface
Read it from here , will hopefully clear most of your doubts.
An API stands for Application Programming Interface, which means using and existing program or code and accessing it with your code.
===
Example, Search Engine:
Search engine 1: offers search and api (if you want this can be google)
Search engine 2: uses googles api to get results (this is your one)
To get results you basically search the other search engine and get their results to yours
====
An API can be used in many ways, to access others data or code, ect
An in-depth explination can be found here: http://en.wikipedia.org/wiki/Application_programming_interface
An application-programming interface (API) is a set of programming instructions and standards for accessing a Web-based software application or Web tool. A software company releases its API to the public so that other software developers can design products that are powered by its service.
For example, Amazon.com released its API so that Web site developers could more easily access Amazon's product information. Using the Amazon API, a third party Web site can post direct links to Amazon products with updated prices and an option to "buy now."
An API is a software-to-software interface, not a user interface. With APIs, applications talk to each other without any user knowledge or intervention. When you buy movie tickets online and enter your credit card information, the movie ticket Web site uses an API to send your credit card information to a remote application that verifies whether your information is correct. Once payment is confirmed, the remote application sends a response back to the movie ticket Web site saying it's OK to issue the tickets.
As a user, you only see one interface -- the movie ticket Web site -- but behind the scenes, many applications are working together using APIs. This type of integration is called seamless, since the user never notices when software functions are handed from one application to another.
This article shows an example
http://www.codeproject.com/Tips/127316/Integrate-FB-javascript-API-to-your-asp-net-app-to
I have a website that revolves around transactions between two users. Each user needs to agree to the same terms. If I want an API so other websites can implement this into their own website, then I want to make sure that the other websites cannot mess with the process by including more fields in between or things that are irrelevant to my application. Is this possible?
If I was to implement such a thing, I would allow other websites to use tokens/URLs/widgets that would link them to my website. So, for example, website X wants to use my service to agree user A and B on the same terms. Their page will have an embedded form/frame which would be generated from my website and user B will also receive an email with link to my website's page (or a page of website X with a form/frame generated from my server).
Consider how different sites use eBay to enable users to pay. You buy everything on the site but when you are paying, either you are taken to ebay page and come back after payment, or the website has a small form/frame that is directly linked to ebay.
But this is my solution, one way of doing it. Hope this helps.
It depends on how your API is implemented. It takes considerably more work, thought, and engineering to build an API that can literally take any kind of data or to build an API that can take additional, named, key/value pairs as fields.
If you have implemented your API in this manner, then it's quite possible that users of this API could use it to extend functionality or build something slightly different by passing in additional data.
However, if your API is built to where specific values must be passed and these fields are required, then it becomes much more difficult for your API to be used in a manner that differs from what you originally intended.
For example, Google has many different API's for different purposes, and each API has a very specific number of required parameters that a developer must use in order to make a successful HTTP request. While the goal of these API's are to allow developers to extend functionality, they do allow access to only very specific pieces of data.
Lastly, you can use authentication to prevent unauthorized access to your API. The specific implementation details depend largely on the platform you're working with as well as how the API will be used. For instance, if users must login to use services provided by your API, then a form of OAuth may suffice. However, if other servers will consume your API, then the authorization will have to take place in the HTTP headers.
For more information on API best practices, see 7 Rules of Thumb When You Build an API, and a slideshow from a Google Engineer titled How to Design a Good API and Why That Matters.
What things should a developer designing and implementing an API for a community based website know before starting the heavy coding? There are a bunch of APIs out there like Twitter API, Facebook API, Flickr API, etc which are all good examples. But how would you build your own API?
What technologies would you use? I think it's a good idea to use REST-like interface so that the API is accessible from different platforms/clients/browsers/command line tools (like curl). Am I right? I know that all the principles of web development should be met like caching, availability, scalability, security, protection against potential DOS attacks, validation, etc. And when it comes to APIs some of the most important things are backward compatibility and documentation. Am I missing something?
On the other hand, thinking from user's point of view (I mean the developer who is going to use your API), what would you look for in an API? Good documentation? Lots of code samples?
This question was inspired by Joel Coehoorn's question "What should a developer know before building a public web site?".
This question is a community wiki, so I hope you will help me put in one place all the things that should be addressed when building an API for a community based website.
If you really want to define a REST api, then do the following:
forget all technology issues other than HTTP and media types.
Identify the major use cases where a client will interact with the API
Write client code that perform those "use cases" against a hypothetical HTTP server. The only information that client should start with is the response from a GET request to the root API url. The client should identify the media-type of the response from the HTTP content-type header and it should parse the response. That response should contain links to other resources that allow the client to perform all of the APIs required operations.
When creating a REST api it is easier to think of it as a "user interface" for a machine rather than exposing an object model or process model. Imagine the machine navigating the api programmatically by retrieving a response, following a link, processing the response and following the next link. The client should never construct a URL based on its knowledge of how the server organizes resources.
How those links are formatted and identified is critical. The most important decision you will make in defining a REST API is your choice of media types. You either need to find standard ways of representing that link information (think Atom, microformats, atom link-relations, Html5 link relations) or if you have specialized needs and you don't need really wide reach to many clients, then you could create your own media-types.
Document how those media types are structured and what links/link-relations they may contain. Specific information about media types is critical to the client. Having a server return Content-Type:application/xml is useless to a client if it wants to do anything more than parse the response. The client cannot know what is contained in a response of type application/xml. Some people do believe you can use XML schema to define this but there are several disadvantages to this and it violates the REST "self-descriptive message" constraint.
Remember that what the URL looks like has absolutely no bearing on how the client should operate. The only exception to this, is that a media type may specify the use of templated URIs and may define parameters of those templates. The structure of the URL will become significant when it comes to choosing a server side framework. The server controls the URL structure, the client should not care. However, do not let the server side framework dictate how the client interacts with the API and be very cautious about choosing a framework that requires you to change your API. HTTP should be the only constraint regarding the client/server interaction.